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Abstract 


The  federal  government  has  an  expressed  interest  in  moving  data  and  serviees  to 
third  party  serviee  providers  in  order  to  take  advantage  of  the  flexibility,  sealability,  and 
potential  eost  savings.  This  approach  is  called  cloud  computing.  In  order  to  leverage 
the  cost  advantages  of  cloud  computing,  the  federal  government  must  utilize  public  cloud 
computing  resources  and  techniques  to  mitigate  security  concerns.  The  purpose  of  this 
research  is  to  examine  methodologies  that  may  be  employed  in  order  allow  users  secure 
access  to  public  cloud  computing  resources.  The  thesis  for  this  research  is  that  efficient 
techniques  exist  to  support  the  secure  use  of  public  cloud  computing  resources  by  a 
large,  federated  enterprise.  The  primary  contributions  of  this  research  are  the  novel 
cryptographic  system  MA-AHASBE  (Multi- Authority  Anonymous  Hierarchical  Attribute- 
Set  Based  Encryption),  and  the  techniques  used  to  incorporate  MA-AHASBE  in  a  real 
world  application.  MA-AHASBE  was  developed  specifically  because  the  attribute-based 
encryption  systems  available  did  not  offer  everything  that  would  be  required  in  a  large, 
federated  organization.  MA-AHASBE  allows  users  to  create  ciphertext  that  enforces 
an  access  policy,  allows  policies  to  include  attributes  from  multiple  authorities  in  either 
a  centralized  or  decentralized  environment,  allows  for  protected  attributes  that  are  not 
disclosed  in  the  ciphertext,  and  allows  an  authority  to  delegate  key  generation  capabilities 
to  a  hierarchy  of  subdomains.  The  system  is  described  using  asymmetric  bilinear  maps  over 
pairing  friendly  elliptic  curves,  which  have  been  shown  to  be  the  most  efficient  pairings  in 
practice.  The  second  significant  contribution  of  this  research  is  the  application  of  MA- 
AHASBE  to  a  microblogging  application.  Two  new  security  models  were  developed 
called  A-trusted  and  ACE-trusted.  These  models  focus  on  availability  as  the  key  trust 
requirement  between  a  client  and  a  cloud  service  provider.  The  A-trusted  model  requires 
only  availability  trust,  while  the  ACE-trusted  model  adds  certain  computability  and  access 
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control  enforcement  requirements.  While  this  does  increase  the  trust  required  in  a  cloud 
service  provider,  the  efficiency  gains  can  be  significant  and  the  tradeoff  in  security  seems 
reasonabfe  for  reputabfe  cfoud  service  providers.  Neither  modef  requires  confidentiaiity 
trust,  so  cfoud  service  providers  cannot  team  the  contents  of  data.  In  order  to  support  the 
security  modefs,  a  framework  caffed  Axon  is  presented.  This  framework  demonstrates 
a  fayered,  data  structure  oriented  approach  to  buifding  compfex,  secure  data  structures 
and  protocofs.  This  method  is  used  to  buifd  Critter,  a  secure  microbfogging  appfication. 
Performance  resuits  indicate  that  white  there  is  a  cost  associated  with  enforcing  an  ACE- 
trusted  modef  in  Critter  versus  processing  the  data  in  pfaintext,  the  cost  is  not  unreasonabfe 
and  the  benefits  in  security  can  be  significant.  The  contributions  of  this  research  give  the 
DoD  additionaf  toofs  for  supporting  the  mission  white  taking  advantage  of  the  cost  efficient 
pubfic  cfoud  computing  resources  that  are  becoming  widefy  avaifabfe. 
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I.  Introduction 

CLOUD  computing  can  be  a  divisive  term.  Eor  some  it  means  lower  operating  costs, 
flexible  deployment  options,  and  increased  security.  Eor  many  others  it  can  mean 
something  very  different.  Some  view  cloud  computing  as  inherently  less  secure,  less 
flexible,  and  that  the  lure  of  lower  operating  costs  is  not  as  attractive  as  it  might  seem. 
Others  see  it  as  a  meaningless,  marketing  buzzword  that  only  serves  to  create  confusion 
[48].  Either  way,  the  federal  government  has  an  expressed  interest  in  moving  data  and 
services  to  the  cloud  in  order  to  take  advantage  of  potential  cost  savings  [67].  Cloud 
computing  is  particularly  important  in  the  context  of  the  federal  strategy  to  consolidate 
the  thousands  of  data  centers  owned  and  operated  by  the  government  [66].  In  order  to 
truly  leverage  the  cost  advantages  of  cloud  computing,  the  federal  government  must  utilize 
public  cloud  computing  resources.  However,  naively  moving  sensitive  data  and  services 
to  third  party  servers  may  involve  unnecessary  tradeoffs  in  security.  The  purpose  of  this 
research  is  to  examine  methodologies  that  may  be  employed  in  order  allow  users  secure 
access  to  public  cloud  computing  resources.  The  thesis  for  this  research  can  be  stated  as: 

Efficient  techniques  exist  to  support  the  secure  use  of  public  cloud  computing 
resources  by  a  large,  federated  enterprise. 

This  dissertation  describes  the  work  done  in  supporting  this  claim.  Aside  from  the 
background  material  presented,  the  research  presented  in  this  document  can  be  divided 
into  two  main  areas.  The  first  area  is  the  development  of  a  new  cryptographic  system 
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called  Multi-Authority  Anonymous  Hierarchical  Attribute-Set  Based  Encryption  (MA- 
AHASBE).  This  new  system  presents  a  solution  to  the  problem  of  key  management  that 
is  often  not  addressed  by  research  on  secure  cloud  computing.  The  second  area  presents 
an  application  of  MA-AHASBE  for  performing  secure  services  using  untrusted  servers. 
This  research  presents  a  layered  approach  to  building  secure  services,  in  the  context  of 
an  example  microblogging  application  called  Critter.  This  research  also  presents  a  novel 
security  model  based  on  the  information  security  principle  of  availability.  These  two  areas 
of  the  research,  along  with  background  material,  are  divided  into  the  following  chapters: 

Chapter  2  Provides  background  material  on  cloud  computing  and  its  use  in  the  federal 
government.  It  reviews  important  cloud  computing  terminology  and  service  models 
that  will  be  used  throughout  this  document. 

Chapter  3  Presents  the  mathematical  background  and  context  necessary  to  understand  the 
cryptographic  system  presented  in  Chapters  4  and  5.  Specifically,  this  covers  the 
basics  of  group  theory,  elliptic  curve  cryptography,  and  bilinear  pairings. 

Chapter  4  Introduces  a  novel  cryptographic  system  called  MA-AHASBE.  MA-AHASBE 
is  a  public  key  cryptographic  system  designed  to  support  the  security  requirements 
of  a  large,  federated  enterprise  attribute  based  access  control  (ABAC)  system. 
This  chapter  describes  the  system  components  in  detail,  presents  a  mathematical 
construction,  and  provides  an  argument  for  its  security  in  the  context  of  a  formal 
security  model. 

Chapter  5  Examines  the  performance  characteristics  of  the  MA-AHASBE  system  intro¬ 
duced  in  Chapter  4  through  a  research  implementation.  This  includes  aspects  such 
as  the  size  of  ciphertexts  as  well  as  the  time  required  to  perform  encryption  and  de¬ 
cryption  operations.  This  is  done  in  the  context  of  a  microblogging  application  that 
uses  a  simple  publish-subscribe  mechanism.  This  chapter  also  introduces  a  security 
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model  based  on  the  information  security  principle  of  availability  that  offers  a  dif¬ 
ferent  perspective  than  the  popular  honest-but-curious  security  model.  The  research 
also  presents  a  framework  called  Axon  that  facilitates  building  complex  applications 
under  the  new  security  model  through  a  layered,  data  structure  oriented  approach. 

Chapter  6  Provides  a  summary  of  the  research  contributions  in  this  document  as  well  as 
some  thoughts  on  where  future  work  may  take  place. 

The  primary  contributions  of  this  research  are  the  novel  cryptographic  system  MA- 
AHASBE,  and  the  techniques  used  to  incorporate  MA-AHASBE  in  a  real  world 
application.  MA-AHASBE  was  developed  specifically  because  the  attribute-based 
encryption  systems  available  did  not  offer  everything  that  would  be  required  in  large, 
federated  organization  such  as  the  DoD.  A  primary  goal  of  this  research  is  to  demonstrate 
that  attribute-based  encryption  is  a  viable  option  for  future  applications  and  that  it  provides 
significant  flexibility  that  is  not  possible  with  the  current  DoD  public  key  infrastructure. 
Specifically,  it  allows  applications  to  be  built  that  can  take  advantage  of  the  low  cost  of 
public  cloud  computing  without  making  significant  concessions  in  terms  of  security.  The 
storage  and  processing  needs  of  the  DoD  are  increasing,  but  there  is  also  constant  budgetary 
pressure  to  do  more  with  less.  The  contributions  of  this  research  give  the  DoD  additional 
tools  for  supporting  the  mission  while  taking  advantage  of  the  cost  efficient  public  cloud 
computing  resources  that  are  becoming  widely  available. 
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II.  Cloud  Computing 


This  chapter  discusses  the  basics  of  cloud  computing  and  its  use  in  the  U.S. 
Government.  It  is  divided  into  two  sections.  The  first  section  introduces  cloud  computing 
terminology  and  concepts  that  are  used  throughout  this  document.  The  second  section 
presents  some  key  examples  of  why  the  government  is  interested  in  cloud  computing  and 
provides  a  few  examples  of  how  the  government  has,  albeit  conservatively,  leveraged  the 
public  cloud. 

2.1  Cloud  Computing 

The  term  cloud  computing  is  a  phrase  that  has  become  increasingly  popular  over  the 
last  ten  years.  Figure  2.1  shows  the  usage  of  the  phrase  according  to  Google’s  Ngram 
Viewer  [51],  which  indexes  books  from  1800  to  2008.  Over  time,  cloud  computing  has 
become  the  industry  buzzword  for  the  long  held  dream  of  large  scale  computing  as  a  utility. 
Especially  during  its  initial  growth,  cloud  computing  was  met  with  both  enthusiasm  and 
indifference.  On  the  one  hand,  it  did  not  represent  anything  fundamentally  new  about 
computing  as  much  of  the  technology  (e.g.,  virtualization,  network  security,  distributed 
systems,  computing  as  a  utility)  had  been  researched  extensively  since  the  1960s.  On 
the  other  hand,  the  combination  of  an  expanding  Internet  infrastructure  combined  with 
the  excess  capacity  in  large  scale  data  centers  allowed  computing  to  be  packaged  and 
sold  in  a  way  that  was  not  previously  feasible.  One  of  the  initial  hurdles  in  the  federal 
adoption  of  cloud  computing  was  the  lack  of  a  clear,  widely  accepted  definition.  For 
some,  cloud  computing  was  simply  any  type  of  computing  that  involved  the  Internet. 
For  others  it  was  the  growth  of  Internet  based  applications  such  as  Gmail,  YouTube  or 
SalesForce.com.  In  2009,  the  National  Institute  of  Technology  and  Standards  (NIST)  began 
work  on  standardizing  the  definition  of  cloud  computing.  The  definition  itself  [83]  is  a 
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short,  two-page  description  of  the  key  elements  of  cloud  computing  such  as  its  essential 
characteristics,  service  models  and  deployment  models.  This  definition  helped  establish 
the  conceptual  properties  of  cloud  computing  and  gave  additional  support  to  why  these 
properties  were  distinct  from  other  types  of  computing. 
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Figure  2.1:  Usage  of  the  phrase  cloud  computing 


2.1.1  Cloud  Service  Models. 

In  order  to  facilitate  discussion  of  cloud  computing,  NIST  was  tasked  to  provide  a 
standardized  definition  of  cloud  computing.  As  part  of  this  definition  [83],  NIST  defines 
three  types  of  service  models  that  are  characteristic  of  cloud  service  providers  (CSP).  A 
CSP  may  provide  service  through  one  or  more  of  the  following  service  models'. 

Software-as-a-Service  (SaaS)  The  capability  provided  to  the  consumer  is  to  use  the 
provider’s  applications  running  on  a  cloud  infrastructure.  The  applications  are 
accessible  from  various  client  devices  through  a  thin  client  interface  such  as  a 
web  browser  (e.g.,  web-based  email).  The  consumer  does  not  manage  or  control 
the  underlying  cloud  infrastructure  including  network,  servers,  operating  systems, 
storage,  or  even  individual  application  capabilities,  with  the  possible  exception  of 
limited  user-specific  application  configuration  settings. 
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Platform-as-a-Service  (PaaS)  The  capability  provided  to  the  consumer  is  to  deploy  onto 
the  cloud  infrastructure  consumer-created  or  acquired  applications  created  using 
programming  languages  and  tools  supported  by  the  provider.  The  consumer  does  not 
manage  or  control  the  underlying  cloud  infrastructure  including  network,  servers, 
operating  systems,  or  storage,  but  has  control  over  the  deployed  applications  and 
possibly  application  hosting  environment  configurations. 

Infrastructure-as-a-Service  (laaS)  The  capability  provided  to  the  consumer  is  to  pro¬ 
vision  processing,  storage,  networks,  and  other  fundamental  computing  resources 
where  the  consumer  is  able  to  deploy  and  run  arbitrary  software,  which  can  include 
operating  systems  and  applications.  The  consumer  does  not  manage  or  control  the 
underlying  cloud  infrastructure  but  has  control  over  operating  systems,  storage,  de¬ 
ployed  applications,  and  possibly  limited  control  of  select  networking  components 
(e.g.,  host  firewalls). 

The  NIST  definition  of  cloud  computing  also  provides  the  following  four  deployment 

models: 

Private  Cloud  The  cloud  infrastructure  is  operated  solely  for  an  organization.  It  may  be 
managed  by  the  organization  or  a  third  party  and  may  exist  on  premise  or  off  premise. 

Community  Cloud  The  cloud  infrastructure  is  shared  by  several  organizations  and 
supports  a  specific  community  that  has  shared  concerns  (e.g.,  mission,  security 
requirements,  policy,  and  compliance  considerations).  It  may  be  managed  by  the 
organizations  or  a  third  party  and  may  exist  on  premise  or  off  premise. 

Public  Cloud  The  cloud  infrastructure  is  made  available  to  the  general  public  or  a  large 
industry  group  and  is  owned  by  an  organization  selling  cloud  services. 

Hybrid  Cloud  The  cloud  infrastructure  is  a  composition  of  two  or  more  clouds  (private, 
community,  or  public)  that  remain  unique  entities  but  are  bound  together  by 
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standardized  or  proprietary  technology  that  enables  data  and  application  portability 
(e.g.,  cloud  bursting  for  load  balancing  between  clouds). 

Typically,  the  tradeoffs  of  choosing  between  deployment  models  are  often  between 
cost,  convenience  and  security.  Public  clouds  often  offer  the  greatest  cost  benefit, 
but  traditionally  cause  the  most  uneasiness  with  regards  to  security.  The  federal  and 
Department  of  Defense  (DoD)  strategy  for  cloud  computing  as  discussed  in  §2.2  involve 
all  four  deployment  models  [67,  100].  The  purpose  of  this  research  is  to  look  at  methods 
for  securely  adopting  cloud  computing  using  as  much  of  the  public  cloud  deployment 
model  as  possible,  while  at  the  same  time  limiting  the  information  available  to  the  CSP. 
By  limiting  the  information  available  to  the  CSP,  this  will  hopefully  soften  the  cultural 
barriers  that  exist  for  adopting  cloud  computing  more  broadly  within  the  DoD.  Attribute 
based  encryption  techniques,  such  as  the  one  presented  in  Chapter  4  require  some  type  of 
trusted  server  to  perform  some  of  the  cryptographic  operations.  These  trusted  servers  could 
run  inside  a  private  computing  cloud  such  as  DISA’s  RACE  [2].  This  trusted  component 
should  represent  a  very  small,  relatively  static  portion  of  the  overall  processing  and  storage 
requirements  for  the  overall  application.  The  bulk  of  processing  and  storage  could  still  be 
securely  outsourced  to  public  cloud  computing  resources.  This  configuration  would  fall 
under  the  hybrid  cloud  model  in  the  NIST  definition. 

2.2  Federal  Use  of  Cloud  Computing 

Since  2009,  the  federal  government  has  gradually  taken  a  more  aggressive  approach  to 
cloud  computing  adoption.  Since  that  time,  this  federal  push  known  as  the  Federal  Cloud 
Computing  Initiative  (FCCI)  has  met  with  both  enthusiasm  and  resistance.  The  topic  of 
cloud  computing  in  the  federal  government  is  a  broad  topic,  and  in  fact  entire  books  have 
been  written  on  this  specific  topic  [14,  78].  It  seems  the  most  common  government  use  of 
public  cloud  services  are  for  public  websites.  Private  cloud  services  are  also  being  built  up 
using  the  internal  resources  of  the  various  federal  agencies.  Using  virtualization  alone  does 
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not  necessarily  turn  an  internal  data  center  into  a  private  cloud.  To  fit  the  NIST  definition, 
these  resources  must  be  made  available  as  an  on-demand,  metered  service.  Many  federal 
agencies  are  adopting  this  approach  as  well,  using  central  data  centers  to  provide  cloud 
services  to  smaller  compartments  within  the  agency.  This  section  discusses  some  of  the 
key  elements  of  federal  adoption  of  cloud  computing  including  small  case  studies  on  the 
approach  of  the  Department  of  the  Treasury  and  the  Department  of  Homeland  Security. 

2.2.1  Federal  Data  Center  Consolidation  Initiative. 

One  of  the  modern  drivers  for  cloud  computing,  both  in  industry  and  government, 
is  the  allure  of  reducing  or  eliminating  the  operating  costs  associated  with  running  large 
internal  data  centers.  In  1993,  then  President  Bill  Clinton  asked  Vice  President  A1 
Gore  to  perform  an  internal  review  of  the  federal  government  in  order  to  determine 
areas  where  the  government  could  be  more  efficient.  This  review  was  called  the 
National  Performance  Review.  This  review  contains  a  report  titled  Reengineering  Through 
Information  Technology  [91],  that  identifies  “consolidating  and  modernizing  government 
data  processing  centers”  as  one  of  its  four  proposed  actions.  The  report  cites  a  DoD  plan  to 
consolidate  100  data  centers  into  16  efficient  centers. 

Over  the  next  several  years,  the  need  for  information  processing  would  continue 
to  drive  up  the  number  of  federal  data  centers  in  operation.  In  2009,  another  call  to 
action  came  when  Federal  Chief  Information  Officer  Vivek  Kundra  sent  a  memo  to  all 
federal  agency  CIOs  discussing  the  need  for  data  center  consolidation  [66].  The  memo 
emphasized  that  the  number  of  federal  data  centers  had  grown  considerably  over  the 
previous  decade  (from  432  in  1998  to  over  1,100  in  2009).  The  memo  asked  the  CIOs 
to  evaluate  their  agencies  to  find  ways  to  either  reduce  data  center  requirements  either 
through  server  virtualization  or  through  cloud  computing.  This  feedback  led  to  the  Federal 
CIO  publishing  a  25  point  implementation  plan  for  the  Federal  Data  Center  Consolidation 
Initiative  (FDCCI)  [65].  Point  3  in  this  plan  called  for  a  “shift  to  a  cloud  first  policy”. 
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This  required  government  agencies  to  default  to  a  cloud-based  solution  when  appropriate 
for  all  new  IT  deployments.  These  cloud  solutions  could  leverage  private  government 
clouds,  commercial  public  clouds,  or  regional  (i.e.,  community)  clouds  for  state  and  local 
governments.  In  order  to  support  this  cloud  first  policy,  the  Federal  CIO  was  required  to 
publish  a  federal  cloud  strategy.  This  strategy  document  was  published  three  months  later 
in  February  of  201 1  [67]. 

The  progress  of  the  FDCCI  to  reduce  data  centers  and  realize  cost  savings  of  $2.4 
billion  by  2015  has  been  difficult  to  measure.  One  reason  for  this  difficulty  is  that  the 
definition  for  what  constitutes  a  data  center  has  changed  throughout  the  program.  Initially 
the  Office  of  Management  and  Budget  (0MB)  laid  out  specific  requirements  in  terms  of 
size,  purpose  and  availability.  For  example,  the  data  center  must  provide  at  least  500  sq 
ft  of  floor  space  for  equipment.  The  initial  FDDCI  memo  [66]  (published  in  February  of 
2010)  stated  that  there  were  “more  than”  1,100  federal  agency  data  centers  in  2009.  The  25 
Point  Implementation  Plan  (published  in  December  of  2010)  states  that  there  were  2,094 
data  centers  in  2010.  This  would  be  a  near  doubling  in  the  course  of  only  a  year.  In 
October  2011,  the  Federal  Chief  Information  Officer  (CIO)  redefined  data  center  to  include 
facilities  of  any  size.  Using  this  new  definition,  the  0MB  reported  that  there  were  3,133 
data  centers.  As  agencies  began  applying  the  new  definition,  the  number  of  data  centers 
increased  dramatically.  In  2013,  the  Government  Accountability  Office  (GAO)  reported 
6,836  data  centers.  However,  2,200  of  these  “data  centers”  were  actually  server  closets  in 
the  county  offices  of  the  Department  of  Agriculture  that  typically  only  house  a  single  server. 
The  GAO  also  reported  that  the  majority  of  federal  agencies  involved  in  the  program  had 
not  yet  submitted  complete  inventories  or  plans  for  consolidation.  The  GAO  also  reported 
that  there  is  no  established  rule  for  validating  any  cost  savings  estimates  [40,  44]. 

The  DoD  published  a  review  of  its  implementation  of  the  FDCCI  in  April  2013  [39]. 
The  DoD  owns  the  largest  number  of  data  centers  (772)  than  any  other  federal  agency 
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(based  on  definition  as  stated  before).  Aceording  to  the  report,  the  DoD  planned  on 
reducing  the  number  of  data  centers  by  30%  by  the  end  of  2013  and  the  number  of  servers 
by  25%.  The  report  contains  an  interesting  breakdown  of  consolidation  plans  by  branch,  as 
shown  in  Table  2.1. 


Table  2.1:  Data  center  consolidation  plans  by  branch 


Owner 

Current 

Planned 

Air  Force 

137 

117 

Army 

250 

154 

Navy 

78 

77 

Combatant  Commands 

25 

21 

Other 

282 

163 

Total 

772 

532 

Noteworthy  is  that  the  Army  is  listed  as  having  the  most  data  centers,  but  also  plans 
on  reducing  the  most.  The  report  states  that  the  Army’s  consolidation  efforts  began  in  2006 
and  that  it  plans  on  continuing  even  greater  reductions  to  only  65  data  centers  by  2015.  So 
although  the  effectiveness  of  the  FDCCI  at  reducing  the  number  of  federal  data  centers  is 
a  matter  of  some  debate,  the  initiative  has  spurred  significant  interest  at  the  federal  level 
in  transitioning  to  cloud  computing.  It  marked  the  beginning  of  a  policy  that  put  cloud 
computing  at  the  forefront  in  federal  acquisitions  of  new  IT  systems. 

2.2.2  Federal  Risk  and  Authorization  Management  Program  (FedRAMP). 

In  the  spring  of  2009,  Federal  CIO  Vivek  Kundra  began  an  inter-agency  program 
labeled  the  Federal  Cloud  Computing  Initiative  [76,  78].  Coordinated  through  the  General 
Services  Administration,  the  FCCI  would  bring  in  technical  experts  from  various  federal 
agencies  in  order  to  foster  the  adoption  of  cloud  computing.  In  September  2009,  the  FCCI 
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was  more  broadly  announced  by  Mr.  Kundra  in  coordination  with  the  launch  of  a  new  cloud 
computing  online  shopping  portal  apps.gov  [64].  Apps.gov  was  envisioned  to  be  an  inter¬ 
agency  shopping  portal  where  agency  CIOs  could  purchase  pre-approved  cloud  computing 
products  quickly  and  easily.  The  goal  was  to  move  agencies  away  from  their  traditional, 
stove-piped  IT  acquisition  approaches  and  foster  a  shared  approach  to  IT  acquisition. 

One  barrier  to  this  inter-agency  adoption  was  that  each  agency  had  its  own  internal 
processes  for  conducting  certification  and  accreditation  (C&A)  of  information  systems.  To 
address  this  issue,  the  FCCI  established  the  Federal  Risk  and  Authorization  Management 
Program  (FedRAMP).  FedRAMP  was  designed  to  promote  a  “do  once,  use  many  times” 
approach  to  C&A.  Cloud  Service  Providers  (CSPs)  could  be  certified  once  using  a 
comprehensive  set  of  C&A  metrics,  then  the  certification  could  be  used  by  all  federal 
agencies.  This  would  significantly  reduce  the  burden  on  the  federal  agencies  to  conduct 
the  C&A  on  their  own. 

FedRAMP  has  taken  some  time  to  develop.  The  first  formal  policy  memo  was 
published  in  201 1  [104].  The  FedRAMP  Concept  of  Operations  was  published  in  February 
2012  [55].  Initial  operating  capability  was  expected  by  the  end  of  FY12,  with  full 
operational  capability  by  summer  of  2013.  In  May,  2013  there  were  only  two  certified 
CSPs.  As  of  September  2013,  the  number  of  CSPs  has  grown  to  over  nine  and  includes 
popular  public  CSP  Amazon  Web  Services  (AWS).  So  far,  the  focus  appears  to  be  on 
certifying  Infrastructure-as-a-Service  (laaS)  providers  as  all  nine  certified  CSPs  are  for 
laaS. 

2.2.3  Example  from  Department  of  the  Treasury. 

The  Department  of  the  Treasury  has  been  leveraging  cloud  computing  primarily 
through  hosting  of  its  public  facing  websites.  These  sites  include  treasury.gov, 
recovery.gov,  mymoney.gov,  financialstability.gov,  and  makinghomeaffordable.gov  [79]. 
These  sites  are  all  hosted  through  AWS.  According  to  the  Treasury’s  FDCCI  report,  it  was 
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the  first  cabinet  level  agency  to  move  its  public  facing  site  to  the  cloud  where  it  saved  over 
13%  in  monthly  costs  relative  to  the  previous  hosting  solution  [102]. 

Like  many  federal  agencies,  the  Treasury  operates  a  large  internal  IT  infrastructure 
as  well.  In  their  2011  FDCCI  report  [102],  they  reported  to  operate  55  data  centers  with 
around  7,000  servers.  This  document  also  describes  the  Treasury’s  plans  to  leverage  private 
cloud  concepts  with  this  internal  infrastructure.  The  Treasury  plans  on  designating  a  limited 
set  of  data  centers  referred  to  as  “Department  Data  Centers”  which  would  provide  laaS, 
PaaS  and  SaaS  services  to  other  internal  Treasury  bureaus.  However,  the  document  cites 
some  consolidation  concerns  that  may  delay  the  implementation  of  the  plan. 

One  interesting  exception  to  the  consolidation  approach  in  the  Treasury  plan  was  the 
Supervisory  Control  and  Data  Acquisition  (SCADA)  systems  of  the  Bureau  of  Engraving 
and  Printing  (BEP)  and  the  Mint.  The  BEP  website,  which  is  hosted  publicly  on  AWS, 
was  recently  taken  offline  due  to  an  intrusion  in  2010  [56].  These  types  of  attacks  often 
raise  the  most  questions  regarding  public  cloud  computing  security.  It  is  important  to 
recognize  that  these  types  of  attacks  rarely  exploit  any  characteristic  that  is  unique  to  cloud 
computing.  While  the  details  of  how  the  site  was  compromised  are  not  public,  the  most 
likely  explanation  is  that  the  attack  was  possible  through  either  some  security  vulnerability 
in  the  website  code  or  out  of  date  web  server  software.  These  are  both  issues  that  would 
affect  a  website  regardless  of  where  it  is  hosted.  In  these  types  of  cases,  it  is  important  to 
differentiate  between  generic  IT  security  and  cloud  security  [54]. 

2.2.4  Example  from  Homeland  Security. 

The  DHS  also  seems  to  be  very  active  in  adopting  both  public  and  private  cloud 
computing.  In  October  of  2011,  DHS  CIO  Richard  Spires  described  a  variety  of  cloud 
initiatives  in  a  congressional  testimony  given  to  the  House  Subcommittee  on  Cybersecurity, 
Infrastructure  Protection,  and  Security  Technology  [97].  The  testimony  provides  a  fairly 
comprehensive  view  of  DHS  adoption  of  federal  “Cloud  Eirst”  policy. 
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DHS,  like  many  other  agencies,  is  focused  primarily  on  the  two  deployment  models 
of  public  clouds  and  private  clouds.  Mr.  Spires  cites  three  examples  of  how  DHS  is 
using  public  cloud  services.  The  first  is  an  identity  proofing  solution  designed  to  meet 
United  States  Citizenship  and  Immigration  Services’  E- Verify  Self  Check  requirement 
that  allows  individuals  and  employers  to  check  their  employment  eligibility  status  seeking 
employment.  Mr.  Spires  states  that  this  is  the  first  online  E- Verify  program  to  offer  such 
as  service  directly  to  workers.  Next,  DHS  uses  the  cloud  to  provide  Enterprise  Delivery 
Network  (EDN)  services  for  its  public  facing  websites.  This  service  is  used  to  deliver 
content  for  over  70%  of  DHS  websites.  Mr.  Spires  cites  that  in  2009,  when  several  federal 
agencies  came  under  a  denial-of-service  attack  (and  DHS  sites  themselves  experienced 
over  a  100  fold  increase  in  traffic)  that  the  cloud  EDN  service  was  able  to  scale  and  as  a 
result  DHS  sites  experienced  no  outages.  Einally,  DHS  plans  to  move  additional  sites  to 
public  cloud  hosted  infrastructures  over  the  next  two  years.  These  include  sites  from  U.S. 
Immigration  and  Customs  Enforcement  (ICE),  United  States  Citizenship  and  Immigration 
Services  (USCIS),  and  Eederal  the  Emergency  Management  Agency  (EEMA). 

In  addition  to  using  public  cloud  services,  DHS  also  plans  on  building  private  cloud 
services  using  its  internal  infrastructure.  DHS  plans  on  leveraging  its  two  enterprise  data 
centers  as  hubs  for  private  cloud  services  to  its  internal  components.  DHS  components 
would  follow  a  cloud  model  of  a  pay-as-you-go  system  in  order  to  use  centralized  services 
from  these  data  centers.  Some  of  the  cloud  services  that  are  already  implemented  or 
currently  planned  include  authentication,  email,  Sharepoint,  project  management  and  laaS. 
DHS  projects  a  cost  avoidance  savings  of  8-10%  from  utilizing  these  private  clouds.  Mr. 
Spires  cites  security  as  a  top  concern  and  explains  that  DHS  private  cloud  services  will  be 
used  to  house  unclassified  but  sensitive  data  while  public  clouds  are  used  for  non-sensitive 
data. 
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III.  Pairing  Based  Cryptography 


The  purpose  of  this  ehapter  is  to  introduce  the  reader  to  some  of  the  fundamental 
concepts  used  throughout  this  document  with  regards  to  pairing  based  cryptography.  In 
a  sense,  this  chapter  aims  to  guide  someone  who  is  new  to  the  world  of  pairing  based 
cryptography  through  the  mathematical  minefield.  Specifically,  the  goal  is  to  convey 
implementation  concepts  at  a  level  that  prepares  the  reader  to  understand  the  mathematics 
presented  in  Chapter  4.  The  chapter  begins  by  discussing  some  of  the  fundamental  concepts 
of  number  theory  and  abstract  algebra  that  are  used  in  pairing  based  cryptography.  Then 
some  of  the  basic  properties  of  bilinear  maps  and  their  implementations  are  presented.  This 
helps  the  reader  better  understand  the  implementation  presented  in  Chapter  5  which  relies 
heavily  on  bilinear  maps.  Finally,  some  basic  cryptographic  concepts  are  presented  so  the 
reader  has  a  better  understanding  of  the  security  properties  discussed  in  this  research.  The 
scope  of  this  chapter  is  to  briefly  introduce  the  topics  at  a  level  so  that  the  more  formal 
mathematical  constructions  presented  in  Chapter  4  are  more  accessible.  References  are 
provided  throughout  the  chapter  to  more  established  work  for  readers  who  desire  a  deeper 
understanding  of  the  concepts. 

3.1  Mathematics  Primer 

The  world  of  pairing  based  cryptography  has  many  real  world  practical  applications, 
but  also  presents  an  interesting  challenge  to  newcomers  to  the  field.  On  the  one  hand, 
pairings  can  be  treated  in  the  abstract  as  black  box  functions.  These  pairings,  also  known 
as  bilinear  maps,  have  relatively  straightforward  algebraic  properties  that  are  fairly  easy 
to  understand  and  apply.  However,  if  one  desired  to  make  one  of  these  black  boxes,  the 
mathematical  sophistication  required  increases  significantly  and  one  can  quickly  be  lost 
in  the  mathematics.  Moreover,  these  more  sophisticated  concepts  tend  to  come  from  the 
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study  of  number  theory,  abstract  algebra,  and  elliptic  curves.  These  topics  have  a  rich 
(perhaps  daunting)  set  of  terminology  and  concepts,  only  which  a  small  subset  that  applies 
to  pairings. 

Even  though  pairings  can  largely  be  viewed  as  black  boxes,  not  all  pairing  black 
boxes  behave  the  same  way.  For  example  in  [43],  the  authors  explain  the  pitfalls  and 
assumptions  that  need  to  be  made  about  how  these  black  boxes  are  influenced  by  the 
underlying  implementation.  This  implies  that  a  user  of  a  cryptographic  library  that  offers 
pairing  support  needs  to  understand  some  aspects  of  the  underlying  implementation  in  order 
to  avoid  misusing  the  library  (perhaps  leading  to  significant  security  flaws). 

3.1.1  Abstract  Algebra. 

Abstract  algebra  is  both  a  broad  and  deep  field.  This  section  serves  to  briefly  introduce 
a  few  elementary  concepts  to  help  the  reader  understand  the  notation  and  mathematics 
presented  in  Chapter  4.  This  section  also  forms  the  basic  foundation  needed  to  understand 
the  next  section  on  bilinear  maps.  The  material  from  this  section  including  all  definitions 
and  theorems  is  primarily  derived  from  the  lecture  notes  for  the  AFIT  course  MATH  63 1 
[38]  and  from  the  book  on  identity  based  encryption  by  Martin  [74].  The  latter  contains 
an  excellent  introduction  to  the  mathematics  behind  pairings.  Another  book  by  Chatterjee 
[30]  also  provides  a  good  review  of  the  relevant  mathematics.  These  accepted  theorems 
are  presented  in  this  section  without  proof,  but  the  proofs  can  be  found  in  any  standard 
reference  text  on  abstract  algebra  such  as  [?  ]. 

3.1.1. 1  Notation. 

Some  common  mathematical  notation  used  throughout  this  document  is  presented  in 
Table  3.1. 
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Table  3.1:  Mathematical  Notation 


Symbol 

Definition 

Z 

The  integers  {...,  -2,  -1,0, 1,2, ...} 

The  integers  modulo  n.  The  modulus  n  typically  indicates  a  composite 

number,  while  p  ox  q  indicate  a  prime  modulus. 

K 

The  non-zero  elements  of  Z„ 

¥p  or 

A  finite  field  of  size  p  where  p  is  prime.  When  q  is  used  as  the  field 

size,  it  represents  q  =  p'^  where  kisa  positive  integer.  This  represents  an 

extension  field  of  degree  k. 

E(¥p) 

An  elliptic  curve  defined  over  a  finite  field. 

V 

“for  all”.  Typically  used  to  refer  to  all  elements  of  a  set. 

6 

Used  to  denote  a  negligible  function.  Informally,  a  negligible  function  is 

one  whose  inverse  ^  cannot  be  bounded  by  a  polynomial  function.  See 

[73]  for  a  formal  definition. 

6j/ 

Indicates  that  the  element  is  sampled  uniformly  (i.e.,  randomly)  from 

the  set. 

3. 1.1.2  Groups. 

Groups  form  an  important  part  of  cryptography  and  are  used  extensively  throughout 
Chapter  4.  A  group  is  essentially  a  set  of  items  along  with  a  binary  operation,  formally 
defined  below: 

Groups 

(a)  A  binary  operation  on  a  set  G  is  a  function  that  assigns  an  element  of  G  to  every 
pair  of  elements  of  G,  that  is,  a  function  ★  :  G  x  G  G.  Given  a,b  e  G,  we  denote 
★(a,  b)  simply  as  aic  b. 
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(b)  A  group  is  a  set  G  along  with  a  binary  operation  ★  that  has: 


(i)  associativity:  a  ★  (Z?  ★  c)  =  (a  ★  Z?)  ★  c  for  all  a,b,c  &G 

(ii)  an  identity  element:  there  exists  e  6  G  such  that  e  ★  a  =  a  =  a  ★  e  for  all  a  6  G 

(iii)  inverses:  for  every  a  £  G,  there  exists  b  £  G  such  that  a-kb  =  e  =  b-ka 

A  group  is  called  commutative  (Abelian)  if  we  further  have: 

(iv)  commutativity:  a  -k  b  =  b  ir  a  for  all  a,b  £  G 

As  long  as  the  set  and  the  operation  satisfy  these  properties,  the  set  and  operation  are  said 
to  form  a  group.  There  are  numerous  mathematical  constructs  that  satisfy  these  properties. 
The  two  that  are  of  interest  in  this  work  are: 

•  The  integers  modulo  a  prime  under  multiplication  (Zp 

•  Points  on  an  elliptic  curve  (discussed  in  more  detail  in  §3.1.2) 

When  writing  group  operations,  it  can  be  convenient  to  borrow  conventions  from  basic 
addition  and  multiplication.  This  is  called  either  additive  or  multiplicative  notation  respec¬ 
tively.  Take  for  example  the  following  group  operations: 

{{a'ka)'ka)'kb  =  a'ka'ka'kb 

Note  that  we  can  drop  the  parentheses  since  group  operations  are  associative.  If  we  use 
an  additive  notation  (the  ~  symbol  here  indicates  the  change  in  formal  notation  to  additive 
notation),  we  use  the  rules  of  addition  for  combining  like  terms: 

a'ka'kak:b~a  +  a  +  a  +  b  =  3a  +  b~  (3a)  -k  b  =  3a  -k  b 
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The  a  terms  combine  and  an  integer  coefficient  is  used  to  determine  how  terms  have  been 
combined.  This  coefficient  has  higher  precedence  than  the  group  operation  and  so  the 
parenthesis  can  still  be  removed.  Here  is  the  same  set  of  operations  using  multiplicative 
notation: 

aica'kairb^a*a*a*b  =  a^b  ~  *  b  =  a^b 

When  using  multiplicative  notation,  the  number  of  combined  terms  is  represented  in  the 
exponent.  Also,  unlike  additive  notation,  the  group  operator  often  does  not  need  to  be  ex¬ 
plicitly  represented  since  it  is  implied  by  writing  terms  next  to  each  other.  Traditionally, 
additive  notation  is  used  only  for  commutative  (also  called  Abelian)  groups.  Multiplica¬ 
tive  notation  is  used  more  generally,  often  when  it  is  either  unknown  or  unimportant  if 
the  group  is  commutative.  In  this  document,  members  of  the  group  Z*  are  written  using 
multiplicative  notation  and  points  on  elliptic  curves  are  written  additively. 

The  following  are  some  important  facts  to  know  about  groups: 

For  any  group  G: 

(a)  The  identity  element  is  unique:  there  is  exactly  one  element  1  6  G  ( when  written  in 
multiplicative  notation)  that  satisfies  \  *  a  =  a  =  a*  I  for  all  a  £  G.  When  written  in 
additive  notation,  the  identity  element  is  0  £  G  such  that  0  +  a  =  a  =  a  +  0. 

(b)  Inverses  are  unique:  for  any  a  £  G,  there  is  exactly  one  element  b  £  G  such  that 
a*b  =  \  =  b*a;  this  dementis  usually  denoted  as  a~^  when  written  in  multiplicative 
notation  or  as  -a  when  written  in  additive  notation. 

(c)  {arfi~^  =  a  for  any  a  £  G. 

(d)  (a  *  b)~^  =  b~^  *  a~^  for  any  a,b  £  G. 
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3.1.2  Elliptic  Curves. 

Elliptic  curves  are  an  important  part  of  modern  cryptography  and  are  used  as  the  un¬ 
derlying  implementation  for  the  bilinear  maps  described  in  the  next  section.  This  section 
briefly  describes  elliptic  curves.  For  a  more  detailed  treatment  of  elliptic  curves  and  their 
uses  in  cryptography  see  [15].  Elliptic  curves  are  curves  that  can  be  written  in  the  form: 

+  ax  +  b 

When  elliptic  curves  are  plotted  over  the  real  numbers,  the  shape  of  the  curve  is 
influenced  by  the  values  of  the  constants  a  and  b.  The  shape  of  the  curve  for  various  values 
of  a  and  b  are  shown  in  Figure  3.1.  However,  when  using  elliptic  curves  in  cryptography, 
elliptic  curves  are  almost  always  used  over  a  finite  field.  The  result  of  plotting  an  elliptic 
curve  over  a  finite  field  is  shown  in  Figure  3.2. 

There  are  two  aspects  of  elliptic  curves  that  make  them  useful  for  doing  cryptography. 
First  is  that  there  is  an  operation  in  which  the  points  of  an  elliptic  curve  form  a  group. 
In  other  words,  it  is  possible  to  take  any  two  points  on  an  elliptic  curve  and  apply  the 
group  operation  to  get  another  point  on  the  same  curve.  This  group  operation  fulfills  all 
the  requirements  for  points  on  an  elliptic  curve  to  be  group  elements  (e.g.,  it  is  associative, 
there  is  an  inverse  for  every  element,  there  is  an  identity  element).  Although  the  group 
operation  is  a  relatively  simple  algorithm,  it  is  not  described  here  and  instead  the  reader  is 
directed  to  [15]  for  details.  It  is  noteworthy  that  elliptic  curve  points  form  a  commutative 
group,  and  are  therefore  often  written  additively.  This  is  the  convention  followed  in  this 
research. 

The  second  aspect  of  elliptic  curves  that  make  them  useful  for  cryptography  is 
that  certain  mathematical  problems  are  particularly  difficult  to  solve  when  using  elliptic 
curves.  The  difficulty  of  solving  mathematical  problems  typically  forms  the  basis  of  a 
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Figure  3.1:  Elliptic  curves  over  the  real  numbers  with  different  values  for  constants  a  and 
^[3] 


cryptographic  algorithm,  so  when  the  problem  is  more  difficult  the  resulting  cryptographic 
algorithm  can  often  be  more  efficient  (i.e.,  use  smaller  parameters  which  often  leads  to 
better  performance).  In  particular,  the  discrete  logarithm  problem  (discussed  in  more 
detail  later  in  §3.3)  is  harder  for  elliptic  curve  groups  than  it  is  for  groups  such  as  the 
multiplicative  group  of  a  finite  field  which  is  what  cryptographic  algorithms  such  as  RSA 
use  (even  though  the  RSA  algorithm  is  based  on  the  difficulty  of  factoring,  it  has  been 
shown  that  factoring  reduces  to  solving  discrete  logarithms  [5,  53]).  Because  of  this. 
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Figure  3.2:  Elliptic  curve  defined  over  the  finite  field  Zgi  [3] 


the  parameters  for  elliptic  curve  group  elements  can  be  much  smaller  than  RSA  group 
elements. 

3.2  Bilinear  Maps  (Pairings) 

Bilinear  maps  (also  known  as  pairings)  have  become  an  important  part  of  cryptogra¬ 
phy,  especially  since  their  ground  breaking  role  in  solving  the  open  problem  of  identity 
based  encryption  [18]  in  2001.  Since  that  time,  pairings  have  played  a  role  in  increasingly 
more  complex  and  expressive  cryptosystems.  Pairing  based  cryptography  is  something  of 
a  dichotomy.  On  the  one  hand,  the  algebraic  rules  for  pairings  are  relatively  straightfor¬ 
ward  and  easy  to  apply  and  understand.  On  the  other  hand,  the  implementation  of  pairings 
requires  complex  mathematical  concepts  and  algorithms. 

This  section  on  bilinear  maps  has  two  purposes.  The  first  purpose  of  this  section  is 
to  demonstrate  the  algebraic  properties  of  pairings  so  that  the  system  presented  in  Chapter 
4  can  be  understood.  Secondly,  this  section  introduces  some  of  the  issues  involved  with 
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implementing  pairings.  Knowing  some  additional  detail  about  how  the  pairings  are  actually 
implemented  will  also  help  the  reader  to  understand  the  implementation  performance 
details  discussed  in  Chapter  5. 

3.2.1  Pairing  Types. 

There  are  a  few  different  ways  to  classify  pairing  implementations.  One  way  to  do 
so  is  by  classifying  an  implementation  as  either  symmetric  or  asymmetric.  A  symmetric 
pairing  has  the  following  form: 


e  GiXGi  ^  Gt 

A  symmetric  pairing  takes  two  elements  from  the  same  group  and  maps  them  to  an  element 
of  the  target  group.  An  asymmetric  pairing  has  the  following  form: 


e  :  Gi  X  G2  — >  Gt 

An  asymmetric  pairing  takes  elements  from  two  different  groups  and  maps  them  to  a  target 
group  element.  In  both  symmetric  and  asymmetric  pairings,  the  order  of  all  groups  is 
the  same.  The  order  of  the  group  can  either  be  prime  or  composite.  Current  pairing 
implementations  use  points  on  an  elliptic  curve  as  the  elements  of  Gi  and  G2.  Gt  is  the 
multiplicative  group  of  a  finite  field. 

Another  popular  method  of  classifying  pairings  comes  from  the  paper  by  Galbraith  et. 
al  [43].  Pairings  are  classified  into  one  of  three  types: 

Type-1:  Gi  =  G2, 

Type-2:  Gi  ^  G2  but  there  is  an  efficiently  computable  homomorphism  ^  :  G2  ^  Gi; 

Type-3:  G\  4^  G2  and  there  are  no  efficiently  computable  homomorphisms  between  Gi 
and  G2; 
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For  Type-2  and  Type-3  pairings,  there  is  also  no  efficiently  computable  homomorphism 
from  Gi  to  G2  (since  G\  =  G2  for  Type-1  pairings,  there  is  a  trivial  homomorphism). 
In  terms  of  the  earlier  classification,  a  Type-1  pairing  would  be  considered  a  symmetric 
pairing,  while  Type-2  and  Type-3  pairings  are  considered  to  be  asymmetric.  The  choice  of 
pairing  implementation  can  have  significant  impact  on  what  types  of  operations  can  be  done 
and  how  efficient  those  operations  will  be.  Some  of  these  consequences  are  apparent  to  the 
cryptographic  designer;  for  example,  a  security  proof  may  rely  on  the  fact  that  there  is  a 
homomorphism  from  G2  to  Gi  and  therefore  the  scheme  must  be  implemented  with  a  Type- 
2  pairing.  Other  consequences  can  be  more  subtle.  For  example  it  may  not  be  possible  to 
hash  to  elements  of  G2,  elements  of  Gi  may  be  large  (and  therefore  less  efficient  to  compute 
with),  or  it  may  even  be  difficult  to  generate  parameters  with  high  security  in  polynomial 
time.  Table  1  in  [43]  provides  a  good  view  of  the  functionality  and  limitations  for  each  type 
of  pairing. 

In  practice,  Type-3  pairings  are  considered  to  be  the  most  efficient  [9,  10,  21,  41,  42]. 
As  discussed  in  the  next  section,  there  are  pairing  friendly  curves  that  support  optimally 
efficient  pairing  algorithms  at  the  128-bit  security  level.  Type-3  pairings  also  allow  hashing 
to  G2,  random  sampling  of  G2,  use  large  characteristic  finite  fields  (which  make  them 
immune  from  recent  improvements  [62]  of  discrete  logarithm  algorithms  that  require  finite 
fields  with  small  characteristic),  and  the  system  parameters  are  efficiently  computable.  As 
such,  the  research  in  this  paper  uses  Type-3  pairings. 

3.2.2  Pairing  Algebra. 

The  defining  characteristic  of  a  bilinear  map  is  of  course  its  bilinearity.  Take  for 
example^  the  asymmetric  case: 

For  P\,Q\  6  Gi  and  P2,  Qi  e  G2  then: 

e(Pi,P2  +  Q2)  =  e{PuP2)e{Pi,Q2)  and  e{Pi  +  Qi,P2)  =  e(Pi,  P2)e(Qi,  P2). 

'Note  the  convention  used  throughout  this  document  is  that  the  elements  being  paired  are  written  using 
additive  notation,  while  the  result  of  the  pairing  operation  is  written  using  multiplicative  notation 
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This  leads  to  a  relatively  straightforward  algebraic  behavior.  Exponents  of  the  target 
element  can  be  brought  down  as  coefficients  to  either  side  of  the  pairing  (or  as  exponents  if 
the  elements  being  paired  are  written  using  multiplicative  notation).  For  example: 

For  P\  6  Gi  and  Q2  6  G2  then: 

e(Pu3Q2)  =  e(PuQ2?  =  e(3P,,Q2) 

e(3PiAQ2)  =  e(Pu  Q2?*^  =  e{P,,  Q2A  =  e{AP,,3Q2)  =  e{Pu  I2Q2) 

The  example  above  could  have  been  written  completely  in  multiplicative  notation  by 
converting  each  coefficient  to  an  exponent.  Note  how  in  the  example,  the  coefficients  are 
able  to  switch  places  not  only  with  the  exponent,  but  can  be  moved  back  down  to  either 
inner  term.  This  ability  to  move  around  exponents  and  coefficients  is  what  makes  the 
bilinear  map  so  useful  for  building  cryptographic  systems. 

3.3  Cryptography 

Cryptography  is  a  diverse  and  complex  field.  This  section  is  intended  to  briefly 
highlight  some  of  the  key  aspects  of  cryptography  that  are  used  in  this  research.  For  more 
detailed  treatment  of  cryptography,  or  of  the  topics  listed  in  this  section  see  [63,  73]. 

3.3.1  Semantic  Security. 

Semantic  security  is  the  idea  that  a  ciphertext  should  leak  no  information  about  its 
corresponding  plaintext.  One  way  to  achieve  semantic  security  is  through  perfect  secrecy, 
in  other  words  through  the  use  of  a  one-time  pad.  A  one-time  pad  is  a  random  bit 
string  that  is  as  long  as  the  message.  The  pad  is  used  as  a  key  by  performing  an  XOR 
operation,  bit  by  bit,  with  the  message  to  create  the  ciphertext.  While  this  provides 
very  strong  security,  it  becomes  very  impractical  with  large  messages  and  maintaining 
or  transferring  the  one-time  pads  can  become  difficult.  An  alternative  approach  is  to 
ensure  that  given  a  ciphertext,  determining  information  about  the  plaintext  should  be 
computationally  infeasible  by  any  probabilistic,  polynomial-time  algorithm  (PPTA).  This 
idea  was  first  introduced  by  Goldwasser  and  Micali  as  probabilistic  encryption  [49]. 
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Goldwasser  and  Micali  show  that  semantic  security  is  equivalent  to  the  notion  of 
ciphertext  indistinguishability .  Ciphertext  indistinguishability  typically  takes  one  of  two 
forms,  depending  on  the  information  available  to  an  adversary.  These  two  forms  are  chosen 
plaintext  attack  (CPA)  and  chosen  ciphertext  attacks  (CCA).  Typically  the  semantic  security 
definition  for  a  cryptosystem  is  presented  in  terms  of  a  game  between  a  challenger  and  an 
adversary.  The  challenger  performs  any  setup  work  and  presents  any  public  parameters 
to  the  adversary.  To  model  a  chosen  plaintext  attack,  the  adversary  is  able  to  choose  two, 
equal  length  messages  to  be  encrypted  and  submits  the  messages  to  the  challenger.  The 
challenger  picks  one  of  the  messages  at  random,  encrypts  the  message  and  then  returns 
the  ciphertext  back  to  the  adversary.  The  adversary  must  determine  from  the  ciphertext 
which  of  the  two  messages  was  chosen  and  makes  a  guess.  The  adversary  is  said  to  have  an 
negligible  advantage  if  the  guess  is  correct  50%  of  the  time  plus  some  negligible  amount. 
This  negligible  amount  is  usually  defined  mathematically  as  a  function  (represented  in  this 
document  as  e)  whose  inverse  cannot  be  bounded  by  a  polynomial.  The  CCA  game  is 
very  similar  except  that  the  adversary  is  given  access  to  a  decryption  oracle,  which  allows 
decryptions  of  any  ciphertext  the  oracle  is  given.  The  adversary  can  use  this  oracle  on  any 
ciphertext  except  the  challenge  ciphertext  that  is  returned  to  it  (otherwise  the  game  would 
become  trivial).  If  the  adversary  is  allowed  to  adjust  its  strategy  based  on  prior  decryptions, 
this  is  called  adaptive  CCA  (or  sometimes  CCA2).  Non-adaptive  CCA  is  sometimes  called 
CCAl.  The  target  level  of  security  for  a  public  key  cryptosystem  is  either  CCAl  or  CCA2 
security. 

3.3.2  Complexity  Assumptions. 

Most  cryptosystems  are  built  from  the  idea  that  certain  problems  in  mathematics  are 
generally  assumed  to  be  computationally  hard  [75].  This  means  that  for  these  problems, 
there  are  no  known  efficient  (i.e.,  polynomial  time)  algorithms  that  can  solve  them.  Some 
problems  are  considered  to  be  widely  studied  and  thus  there  is  more  confidence  in  the 
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validity  of  the  assumptions.  The  assumptions  corresponding  to  these  problems  are  referred 
to  as  standard  assumptions,  and  cryptosystems  that  only  require  these  types  of  assumptions 
are  said  to  be  secure  in  the  standard  model.  Standard  model  security  is  typically  the  goal  for 
any  cryptosystem  as  it  provides  the  greatest  confidence  in  terms  of  security;  however,  this 
security  may  often  be  difficult  to  obtain.  Often,  in  order  to  prove  security  cryptosystems, 
one  must  rely  on  stronger^  assumptions  instead  of  weaker  standard  assumptions. 

One  way  to  define  assumptions  is  through  a  statistical  game.  An  algorithm  is  said  to 
have  an  advantage  in  the  game  if  it  is  able  to  produce  results  that  are  different  than  random 
guessing.  The  following  is  a  list  of  a  few  common  standard  assumptions  presented  in  this 
format: 

Discrete  Logarithm  (DL)[1]:  Let  G  be  a  cyclic  group  with  generator  g.  Let  D  be  the 
following  distribution: 


^  -  (*G,g,  g^);  X  £u  Z 

The  DL  problem  to  compute  x  £  Z  when  given  D.  Let  Jl  be  an  polynomial-time 
algorithm  that  takes  D  as  its  input  and  produces  as  its  output  .r  e  G.  The  advantage  of 
an  algorithm  Jl  in  solving  the  DL  problem  is  given  by: 

Adv“  =  \Pr[x  =  x^ 

The  (6,  0-DL  assumption  holds  in  G  if  for  any  adversary  ^  running  in  time  at  most  t, 
Adv“  <  6. 

The  discrete  logarithm  problem  is  a  classical  hard  problem  used  in  many  cryptosystems. 
It  represents  a  class  of  problems  where  computing  forward  is  computationally  easy,  but 
reversing  that  computation  is  expensive.  In  this  case,  computing  the  discrete  exponential 

^With  complexity  assumptions,  weaker  assumptions  assume  less  than  strong  assumptions.  Therefore, 
weaker  assumptions  are  usually  more  desirable  in  terms  of  security  than  strong  assumptions.  It  is  an  ironic 
twist  of  mathematical  terminology  where  weak  is  good  and  strong  is  not  as  good. 
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in  the  problem  above  (i.e.,  computing  forward)  is  a  very  efficient  computation. 
However,  the  best  known  algorithms  for  reversing  this  computation  (i.e.,  taking  the  discrete 
logarithm)  are  expensive.  The  cost  of  the  algorithm  depends  on  the  structure  of  the 
underlying  group.  For  generic  groups  (i.e.,  no  special  structure  is  assumed  in  the  structure 
of  the  group  other  than  those  specified  in  the  group  definition),  the  best  known  algorithms 
are  exponential.  For  some  groups,  such  as  points  on  elliptic  curves,  the  generic  algorithms 
are  the  most  efficient  that  are  known.  For  other  groups,  such  as  F*,  then  the  structure  of 
the  group  can  be  exploited  and  sub-exponential  (but  not  polynomial)  algorithms  are  known 
to  exist.  The  security  of  a  cryptosystem  is  dependent  on  the  efficiency  of  these  algorithms. 
Therefore,  groups  that  have  more  efficient  algorithms  (e.g.,  Fp  need  to  be  larger  in  order 
to  provide  the  same  level  of  security  as  groups  with  only  generic  algorithms  (e.g.,  elliptic 
curve  groups). 

Decisional  Diffle-Hellman  (DDH)[1,  63]:  Let  G  be  a  cyclic  group  with  generator  g.  Let 
z  6(7  G.  Let  D  be  the  following  distribution: 

D  =  {G,g\g^);  x,y&u'L 


The  DDH  problem  is  to  determine,  given  (D,  /z  6  G)  if  /z  =  g^^  or  if  h  Sj/  G.  Let  Jl  be 
an  polynomial-time  algorithm  that  takes  (D,  h)  as  its  input  and  produces  1  as  its  output 
ifh  =  g^y  and  0  otherwise.  The  advantage  of  an  algorithm  ^  in  solving  the  DL  problem 
is  given  by: 

Adv^^^  =  |Fr[A(D,g^P  =  1]  -  Pr[A(D,z)  =  1]| 


The  (6,  t)-DDH  assumption  holds  in  G  if  for  any  adversary  ^  running  in  time  at  most 
t,  <  e. 


The  DDH  assumption  is  the  classical  decision  type  assumption.  Many  security  proofs 
rely  on  the  difficulty  of  determining  if  group  elements  have  a  specific  structure  or  if  they 
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are  randomly  sampled.  All  of  the  assumptions  presented  in  Chapter  4  follow  this  pattern. 
The  DDH  assumption  is  considered  to  be  stronger  than  the  discrete  logarithm  assumption, 
because  there  are  groups  where  the  DL  assumption  holds  and  the  DDH  assumption  does 
not.  One  relevant  example  is  with  bilinear  groups.  If  a  symmetric  pairing  is  known  to 
exist  for  G,  then  the  adversary  can  easily  determine  iih  =  The  adversary  is  given 
and  g^ .  The  adversary  can  pair  these  elements  and  get  an  element  m  of  the  target  group 
e{g^,g^)  =  m.  When  the  adversary  receives  h,  it  pairs  it  with  g.lfh  =  g^,  then  this  pairing 
becomes  e(g,  g^^)  =  e(g,  gY^  =  e(g^,  gY  =  m.  If  h  is  random,  then  the  result  is  not  equal  to 
m.  Thus,  the  adversary  can  guess  correctly  after  only  a  single  (efficient)  pairing  operation. 
To  deal  with  the  fact  that  the  DDH  problem  is  easy  in  bilinear  groups,  specialized  DDH 
assumptions  have  been  made  specifically  for  pairings.  An  example  of  such  an  assumption  is 
the  Decisional  Bilinear  Diffie-Hellman  Assumption  for  Type-3  pairings  (DBDH-3)  which 
is  defined  in  Chapter  4. 

3.3.3  Dual  System  Encryption. 

When  cryptosystems  based  on  bilinear  pairings  were  first  introduced,  they  often  relied 
on  a  proof  technique  that  involved  random  oracles  [11].  Cryptosystems  whose  security 
proofs  use  random  oracles  are  said  to  be  secure  in  the  random  oracle  model.  There 
are  known  limitations  to  random  oracles  and  some  in  the  cryptographic  community  see 
cryptosystems  that  rely  on  random  oracles  as  being  disadvantaged  relative  to  cryptosystems 
that  rely  on  more  standard  assumptions.  Eventually,  identity  based  encryption  systems 
were  built  that  did  not  rely  on  random  oracles,  but  required  a  selective-id  security  model. 
This  selective-id  model  required  adversaries  to  announce  their  target  identity  before  even 
seeing  the  public  parameters.  Eventually,  fully  secure  systems  in  the  standard  model  were 
presented,  but  required  large  public  parameters  [109]. 

Typically  to  show  that  a  system  is  secure,  a  simulator  is  used  to  play  out  the  required 
security  game.  Instead  of  being  allowed  to  choose  its  own  parameters,  the  simulator  is  given 
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an  instance  of  some  hard  problem.  Often  this  problem  is  in  the  form  of  distinguishing  some 
element  as  either  having  a  partieular  form  or  being  randomly  seleeted  from  the  group.  The 
simulator  must  use  the  terms  in  the  problem  to  simulate  the  eryptosystem  (i.e.,  perform  all 
the  relevant  ealeulations  for  ereating  eiphertexts  and  keys).  In  order  to  aehieve  full  seeurity, 
a  more  powerful  approaeh  to  building  the  simulator  was  required. 

A  breakthrough  eame  with  the  introduetion  of  the  dual  system  eneryption  method¬ 
ology  by  Waters  [109].  In  a  dual  system  eneryption  system,  there  are  three  types  of 
eomponents:  normal  (sometimes  ealled  fully  funetional),  semi-funetional,  and  nominally 
semi-funetional.  This  applies  to  both  eiphertext  and  keys.  Table  3.2  shows  whieh  eombi- 
nations  lead  to  sueeessful  deeryption  operations  and  whieh  eombinations  lead  to  failure. 
Essentially,  whenever  semi-funetional  eomponents  internet  with  normal  eomponents,  the 
deeryption  is  suoeessful.  However,  whenever  two  semi-funetional  eomponents  are  used, 
the  deeryption  fails.  If  nominally  semi-funetional  eomponents  are  used,  there  is  typieally 
some  speeifie  eondition  that  must  be  met  in  order  for  deeryption  to  be  sueeessful.  This  is 
typieally  used  so  that  the  simulator  eannot  test  if  a  eiphertext  it  is  ereating  is  semi-funetional 
or  not.  In  this  ease,  the  simulator  ean  typieally  ereate  either  normal  or  nominally  semi- 
funetional  eiphertext  and  ean  only  ereate  either  normal  or  nominally  semi-funetional  keys. 
The  simulator  then  eannot  deteet  if  the  eiphertext  is  normal  or  (nominally)  semi-funetional, 
sinee  deeryption  will  be  sueeessful  in  either  ease. 


Table  3.2:  Dual  System  Components  (w/HP  indieates  with  high  probability) 


Keys  \  Ciphertext 

Normal 

Semi-Funetional 

Nominally  Semi-Funetional 

Normal 

/ 

/ 

/ 

Semi-Funetional 

/ 

Fail 

Fail  w/HP 

Nominally  Semi-Funetional 

/ 

Fail  w/HP 

/  (if  eonditions  are  met) 
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The  dual  system  encryption  strategy  works  by  making  an  argument  over  a  sequence 
of  games.  The  first  game  in  the  sequence  is  a  real  security  game  like  those  described 
in  §3.3.1.  The  last  game  is  a  game  where  the  advantage  of  the  adversary  is  known  to 
be  negligible  (e.g.,  the  adversary’s  guess  is  of  a  truly  random  value).  The  games  in 
the  middle  of  the  sequence  are  games  that  leverage  the  ability  of  the  adversary  to  detect 
changes  of  the  components  from  normal  to  semi-functional  to  also  solve  some  complexity 
assumption  (i.e.,  a  known  hard  problem).  For  example,  a  game  might  reduce  the  ability  of 
the  adversary  to  distinguish  between  normal  ciphertexts  and  semi-functional  ciphertexts  to 
solving  DBDH-3.  The  use  of  semi-functional  components  allows  the  challenger/simulator 
to  answer  key  queries  from  the  adversary  without  requiring  any  information  up  front  from 
the  adversary  (unlike  the  selective-id  model  described  above).  The  dual  system  encryption 
approach  has  been  a  very  powerful  one  for  building  pairing  based  cryptosystems  with  full 
security. 
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IV.  MA-AHASBE:  Multi-Authority  Anonymous  Hierarchical 
Attrihute-Set  Based  Encryption 


This  chapter  describes  the  merger  of  two  existing  pairing  based  cryptosystems,  an 
anonymous  hierarchical  identity  based  encryption  (AHIBE)  scheme  and  a  ciphertext- 
policy  attribute-set  based  encryption  (CP-ASBE)  scheme,  into  a  single  system  that 
provides  a  very  rich  feature  set.  The  new  system,  dubbed  MA-AHASBE  (Multi- Authority 
Anonymous  Hierarchical  Attribute-Set  Based  Encryption),  allows  users  to  create  ciphertext 
that  enforces  an  access  policy,  allows  policies  to  include  attributes  from  multiple  authorities 
in  either  a  centralized  or  decentralized  environment,  allows  for  protected  attributes  that 
are  not  disclosed  in  the  ciphertext,  and  allows  an  authority  to  delegate  key  generation 
capabilities  to  a  hierarchy  of  subdomains.  The  system  is  described  using  asymmetric 
bilinear  maps  over  pairing  friendly  elliptic  curves,  which  have  been  shown  to  be  the  most 
efficient  pairings  in  practice.  The  system  is  designed  to  support  the  security  requirements 
of  a  large,  federated  enterprise  attribute  based  access  control  (ABAC). 

4.1  Introduction 

The  introduction  of  pairing  based  cryptography  ignited  the  imaginations  of  cryptogra¬ 
phers  and  created  a  wide  array  of  unique  and  interesting  cryptosystems.  Although  pairings 
had  been  known  to  cryptographers  for  some  time  in  the  context  of  cryptanalysis,  the  first 
pairing  based  encryption  approach  was  proposed  in  2001  by  Boneh-Eranklin  [18].  This  new 
system  solved  a  long  standing  open  problem  proposed  by  Shamir  [95]  regarding  the  exis¬ 
tence  of  identity  based  encryption  (IBE)  systems.  In  an  IBE,  the  user’s  public  key  is  a  fixed 
identifier  such  as  an  email  address  or  URE.  Over  time,  the  concepts  evolved  from  identities 
to  attributes.  A  user  could  have  attributes  assigned  to  them  by  an  authority  through  their 
cryptographic  keys  and  ciphertexts  could  be  created  that  enforced  an  access  policy.  These 
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types  of  systems  are  known  as  ciphertext-policy  attribute  based  encryption  (CP-ABE)  sys¬ 
tems.  This  chapter  presents  a  multi-authority,  anonymous,  hierarchical,  attribute-set  based 
encryption  (MA-AHASBE)  scheme,  which  is  a  type  of  CP-ABE. 

MA-AHASBE  was  developed  to  fill  a  gap  in  CP-ABE  systems.  Many  CP-ABE 
systems  exist  and  come  with  a  variety  of  features  which  are  described  in  more  detail  in  the 
next  section.  While  each  system  presents  a  unique  set  of  novel  features,  no  single  system 
possesses  enough  total  features  required  for  a  large,  federated  system.  Two  systems  in 
particular,  Eewko-Waters  anonymous  hierarchical  identity  based  encryption  (EW-AHIBE) 
[89]  and  ciphertext-policy  attribute-set  based  encryption  (CP-ASBE)  [17],  each  provide 
a  powerful  set  of  capabilities.  However,  they  come  from  slightly  different  worlds,  IBE 
and  CP-ABE.  MA-AHASBE  is  essentially  the  bootstrapping  of  EW-AHIBE  into  an  CP- 
ASBE  system  in  order  to  leverage  the  benefits  of  both  systems.  Some  additional  novel 
machinery  is  added  to  allow  attributes  to  originate  from  multiple  authorities.  The  end 
result  is  a  CP-ABE  with  a  rich  set  of  features  designed  to  support  an  attribute  based  access 
control  (ABAC)  [82]  paradigm  in  a  large,  federated  enterprise  system. 

In  the  following  sections,  we  provide  background  information  that  includes  defini¬ 
tions,  requirements,  and  a  brief  review  of  the  related  work.  We  then  describe  the  notation 
and  functions  used  throughout  the  chapter.  Then  we  give  a  detailed  description  of  the  data 
structures  used  in  MA-AHASBE  to  represent  keys  and  policies.  This  section  also  presents 
the  concepts  of  MA-AHASBE  in  an  informal  setting,  with  motivating  examples.  We  then 
give  a  summary  of  the  algorithms  that  formally  define  MA-AHASBE,  followed  by  a  pro¬ 
posed  construction.  We  conclude  with  a  description  of  the  security  models  and  security 
proof,  as  well  as  some  final  thoughts  on  future  work. 
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4.2  Background 

4.2.1  Enterprise  Attribute  Based  Access  Control  Requirements. 

We  first  discuss  some  requirements  we  argue  are  necessary  for  an  attribute 
based  encryption  (ABE)  scheme  to  serve  as  an  attribute  based  access  control  (ABAC) 
enforcement  mechanism  in  a  large,  federated,  enterprise  environment.  These  requirements 
provide  a  common  framework  to  discuss  both  the  strengths  and  weaknesses  of  other 
systems  for  supporting  such  an  environment.  It  also  provides  insight  to  the  areas  where 
MA-AHASBE  helps  to  provide  missing  capability. 

4.2.1. 1  Definitions. 

Here  we  provide  a  short  list  of  term  definitions.  The  ABAC  and  enterprise  definitions 
come  from  the  NIST  guidance  [58]  on  enterprise  ABAC.  The  domain  definition  is  our  own 
contribution. 

Attribute  Based  Access  Control  (ABAC)  An  access  control  method  where  subject  re¬ 
quests  to  perform  operations  on  objects  are  granted  or  denied  based  on  assigned 
attributes  of  the  subject,  assigned  attributes  of  the  object,  environment  conditions, 
and  a  set  of  policies  that  are  specified  in  terms  of  those  attributes  and  conditions. 

Enterprise  A  collaboration  or  federation  among  entities  for  which  information  sharing  is 
required  and  managed. 

Domain  A  hierarchical  organizational  unit  of  an  enterprise  entity. 

4.2. 1.2  Requirements. 

This  section  briefly  describes  the  requirements  we  argue  are  necessary  for  an  ABE 
to  support  enterprise  level  ABAC.  These  requirements  reflect  our  interpretation  of  the 
guidance  provided  by  NIST  applied  to  the  context  of  ABE  systems.  Eor  each  requirement, 
we  give  a  definition  as  well  as  a  rationale  for  why  it  is  included.  This  list  is  not  meant  to 
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be  exhaustive,  though  it  is  meant  to  represent  a  minimum  set  of  requirements  that  an  ABE 
needs  in  order  to  support  an  enterprise  ABAC. 

Multiple  Authorities  The  system  must  allow  attributes  from  cooperating,  though  author¬ 
itatively  distinct,  authorities  within  a  single  access  control  policy. 

Rationale:  This  capability  allows  a  federated  enterprise  to  share  a  common  attribute 
and  policy  infrastructure. 

Hierarchical  Structure  The  attributes  in  the  system  must  belong  to  a  hierarchical 
structure  that  reflects  the  domain  ownership  of  the  attribute. 

Rationale:  This  is  necessary  in  order  to  properly  determine  which  attributes 
belong  to  which  organizations.  A  large,  federated  organization  may  have  thousands 
of  attributes  that  each  have  domain  specific  meanings.  Allowing  hierarchical 
organization  of  these  attributes  is  necessary  in  order  to  properly  administer  them. 

Hierarchical  Computation  The  computational  burden  of  key  generation  and  manage¬ 
ment  must  primarily  take  place  at  the  same  domain  in  a  hierarchy  as  the  ownership 
of  the  relevant  attributes. 

Rationale:  Key  generation  and  management  may  become  a  bottleneck  for  organi¬ 
zations  with  hundreds  of  thousands  of  users.  A  system  must  allow  for  hierarchical 
computation  in  order  to  distribute  the  workload  more  evenly  across  the  enterprise. 
Note  that  this  does  not  prevent  a  domain  from  utilizing  third  party  computation  or 
storage  resources.  Instead  the  purpose  is  to  limit  the  computational  dependency  be¬ 
tween  domains  or  between  enterprise  entities. 

Hierarchical  Autonomy  Each  domain  of  the  hierarchy  must  be  able  to  generate  arbitrary 
attributes  that  reflect  its  ownership  with  a  minimum  amount  of  coordination  with 
other  enterprise  entities,  including  domains  within  the  same  entity. 

Rationale:  This  requirement  provides  maximum  flexibility  at  the  ABE  level  to  define 
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the  hierarchical  structure  of  attributes.  Note  that  this  requirement  applies  to  the 
ABE,  not  necessarily  to  other  factors  (e.g.,  organization  policy)  that  determine  if 
a  domain  should  generate  a  particular  attribute.  Also  this  requirement  reinforces  the 
requirement  that  a  domain  cannot  generate  attributes  for  other  domains  (i.e.,  each 
attribute  generated  reflects  the  domain  that  owns  that  attribute). 

Attribute  Protection  Policies  must  provide  a  mechanism  to  prevent  sensitive  attributes 
from  being  disclosed  to  unauthorized  parties. 

Rationale:  Often  the  attributes  used  in  access  policies  are  as  sensitive  as  the  objects 
the  policies  are  protecting.  The  attributes  used  in  a  policy  can  disclose  to  third 
parties  what  type  of  information  is  being  protected  or  may  indicate  its  value.  Some 
mechanism  to  protect  these  sensitive  attributes  is  critical  to  the  overall  security 
posture  of  the  system. 

Key  Revocation  The  system  must  provide  a  mechanism  to  revoke  user  keys  that  prevents 
such  keys  from  satisfying  policies  created  after  the  revocation. 

Rationale:  This  supports  the  common  scenario  of  users  leaving  the  system  or  losing 
privileges.  It  is  assumed  that  users  will  be  able  to  decrypt  messages  created  before 
their  key  was  revoked.  The  critical  part  of  the  requirement  is  that  new  messages  will 
be  protected  from  users  with  revoked  keys. 

4.2. 1.3  Features. 

Here  we  list  two  features  that  on  their  own  do  not  justify  themselves  as  requirements, 
but  are  useful  in  the  comparison  of  systems.  We  consider  systems  that  provide  these 
features  to  be  more  supportive  of  an  enterprise  environment  than  those  that  do  not. 

Compound  Attributes  The  system  should  allow  single  attributes  to  be  bound  together 
into  compound  attributes  such  that  they  can  only  be  used  together  to  satisfy  a  policy. 
Rationale:  Compound  attributes  correspond  well  to  scenarios  where  attributes 
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should  only  apply  as  a  group.  For  example  a  course  and  a  grade  could  be  represented 
by  two  attributes,  but  should  be  semantically  bound  together  so  that  the  grade  cannot 
be  used  for  courses  to  which  it  is  not  bound.  In  an  enterprise  environment,  this 
often  occurs  when  people  have  a  combination  of  roles  and  membership  such  as 
"Supervisor"  and  "Human  Resources".  Binding  these  attributes  into  a  compound 
attribute  might  indicate  that  the  user  is  a  supervisor  in  the  Human  Resources 
department.  Keeping  them  separate  may  indicate  that  the  user  is  a  supervisor 
(somewhere,  not  necessarily  of  Human  Resources)  and  a  member  of  the  Human 
Resources  department. 

Numeric  Attributes  and  Comparisons  The  system  should  provide  a  way  to  generate 
numeric  attributes  and  should  allow  policies  to  make  numeric  comparisons  (e.g., 
equality,  less  than,  greater  than). 

Rationale:  Numeric  attributes  and  their  comparisons  in  policies  are  important  in 
many  scenarios.  Critically,  this  includes  the  ability  to  check  timestamps  as  well  as 
numeric  levels  of  access  (e.g.,  distinguishing  a  Level  3  supervisor  from  a  Level  5 
supervisor). 

4.2.2  Related  Work. 

A  significant  body  of  work  has  been  done  in  the  area  of  CP- ABE  systems.  The  first 
construction  was  given  by  Bethencourt  et.  al  in  [13].  Many  others  have  followed  that 
provide  various  enhancements  such  as  proofs  in  the  standard  model  [32,  52],  policy  secrecy 
[69,  80],  and  multi- authority  [28,  29, 70,  72].  In  [71,  108],  the  authors  present  work  that  use 
identities  in  a  hierarchical  IBE  (HIBE)  as  attributes  in  an  ABE.  The  dual  system  encryption 
technique  was  first  developed  by  Waters  [109],  and  has  been  a  very  important  development 
as  it  allows  many  systems  to  be  proven  with  fewer  security  restrictions.  In  [105],  the  authors 
extend  CP-ASBE  [17]  to  a  hierarchical  scheme  called  HASBE.  However,  the  delegation  in 
HASBE  is  restrictive  in  the  sense  that  at  each  level  in  the  hierarchy,  each  domain  can 
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only  restrict  and  cannot  add  to  the  set  of  attributes  available  to  the  next  lower  level  in 
the  hierarchy.  While  proposed  as  a  feature  by  the  authors,  we  see  this  as  a  violation  of 
hierarchical  autonomy.  In  HASBE,  if  a  subdomain  needs  access  to  additional  attributes 
after  its  creation,  there  is  a  substantial  cost  in  adding  that  attribute. 

There  has  also  been  some  recent  work  that  uses  a  pairing  based  system  to  support 
role  based  access  control  RBAC  [111].  Attribute  based  access  control  (ABAC)  can  be  seen 
as  a  generalization  of  RBAC  [58].  The  authors  in  [111]  provide  a  comparison  of  many 
types  of  different  systems  including  hierarchical  identity  based  encryption,  attribute  based 
encryption,  role  based  encryption,  and  hierarchical  key  management.  The  comparison 
looks  very  unfavorable  to  ABE  systems,  however  the  reality  is  more  subtle.  Eor  example, 
ABE  is  cited  as  not  having  constant  size  ciphertext  or  constant  size  keys  when  supporting 
only  one  role.  However,  the  first  system  proposed  in  [1 1 1]  achieves  constant  size  ciphertext 
by  limiting  the  encryption  to  a  single  target  role.  This  is  analogous  to  only  having  a  single 
attribute  in  a  policy.  Since  the  depth  of  the  hierarchy  in  MA-AHASBE  is  bounded  by 
a  constant  at  system  setup  (thus  bounding  the  size  of  the  attributes),  ciphertext  in  MA- 
AHASBE  scales  only  with  the  number  of  attributes  in  the  policy.  A  policy  with  a  single 
attribute  (and  the  associated  ciphertext)  in  MA-AHASBE  is  also  bounded  by  a  constant  in 
this  case.  Eurthermore,  key  structures  in  MA-AHASBE  scale  with  the  number  of  attributes 
a  user  possesses.  So  if  the  number  of  attributes  assigned  to  a  user  is  bound  by  a  constant 
(in  this  comparison  the  constant  is  1),  then  key  size  is  also  constant.  The  authors  in  [111] 
extend  their  first  system  by  allowing  multiple  target  roles,  which  forces  the  ciphertext  to 
scale  with  the  number  of  roles.  Einally,  the  decryption  algorithm  in  both  systems  scales 
linearly  in  both  the  number  of  users  in  the  system  as  well  as  with  the  number  of  ancestor 
roles  (parent  nodes  in  a  role  hierarchy)  of  the  target  roles.  While  the  authors  suggest  this  can 
be  mitigated  since  the  bulk  of  the  computation  can  be  done  without  secret  data  (and  hence 
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can  be  securely  outsourced  to  a  third  party),  this  seems  to  be  overly  burdensome  when 
deploying  to  enterprise  environments  with  large  numbers  of  users  and  roles  (or  attributes). 

There  has  also  been  work  applying  attribute-based  encryption  systems  and  ABAC 
to  an  enterprise  messaging  system  called  Attribute-Based  Messaging  (ABM)  [16].  The 
focus  of  ABM  is  on  the  authorization  and  delivery  of  email  messages  based  on  attributes, 
but  ABM  uses  a  CP-ABE  to  provide  end-to-end  confidentiality.  The  CP-ABE  used  by 
the  authors  of  ABM  is  the  system  proposed  in  [13]  and  implemented  using  the  CP-ABE 
toolkit.  The  Bethencourt  CP-ABE  is  similar  in  its  delegation  capability  as  HASBE,  where 
delegated  keys  may  only  generate  attribute  keys  for  a  restricted  subset  of  attributes.  The 
authors  of  [16]  estimate  that  their  implementation  can  handle  up  to  68,000  users  based  on 
a  weekly  key  refresh  rate  of  one  key  per  week.  The  authors  note  that  without  a  more  robust 
key  management  solution,  key  generation  for  the  ABE  would  likely  become  the  bottleneck 
for  the  entire  system  at  larger  scale.  Since  MA-AHASBE  offers  a  more  robust  and  flexible 
key  delegation  mechanism,  it  could  serve  as  a  drop-in  replacement  in  a  system  such  as 
ABM. 

The  work  on  MA-AHASBE  relies  fundamentally  on  three  previous  works.  MA- 
AHASBE  bootstraps  the  AHIBE  system  described  in  [89]  into  an  attribute-set  system 
described  in  [17].  The  CCA  transform  described  in  [19]  is  then  applied,  leveraging  the 
capabilities  of  the  AHIBE  to  be  able  to  generate  private  keys  for  arbitrary  identities.  Since 
the  design  of  MA-AHASBE  is  heavily  influenced  by  both  CP-ASBE  and  EW- AHIBE,  we 
attempt  to  provide  enough  material  in  the  description  to  make  this  chapter  self-contained. 
However,  the  reader  who  is  unfamiliar  with  these  two  systems  is  highly  encouraged  to 
review  the  cited  references  as  they  naturally  provide  a  much  more  detailed  motivation  and 
exposition. 
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4.3  MA-AHASBE 


4.3.1  Preliminaries  and  Notation. 

4.3.1. 1  Bilinear  Pairings. 

The  construction  for  the  MA-AHASBE  system  is  described  using  asymmetric 
pairings,  also  known  as  Type-3  pairings  [43].  An  asymmetric  pairing  is  a  bilinear  map  from 
Gi  X  G2  to  Gr  where  all  groups  have  prime  order.  A  bilinear  pairing  e  :  Gi  x  G2  ^  Gj- 
must  have  the  following  properties: 

1.  Bilinear.  For  P\,Q\  6  Gi  and  P2,  Q2  6  G2  then: 

e{P i,P2  +  Qi)  =  Qi)  ^nd  e{P  1  +  2i,  E2)  =  e{P i,P2)^{Qi^P2)- 

2.  Non-degenerate:  If  e{Pi,P2)  =  Ir,  the  identity  element  in  Gr,  then  either  Pi  is  the 
identity  of  Gi  or  P2  is  the  identity  of  G2. 

3.  Efficiently  computable:  The  function  e  should  be  efficiently  computable. 

Three  types  of  pairings  have  been  identified.  Type-3  pairings  have  fhe  shortest 
representations  and  the  fastest  algorithms  [89].  Well  known  examples  of  such  pairings 
exists  as  well  as  elliptic  curves  that  support  their  efficient  computation  [35].  Such  curves 
are  known  as  pairing-friendly  curves  [10,  41].  The  term  efficient  is  used  in  the  informal 
sense.  Pairing  computations  on  modern  desktop  hardware  for  finite  fields  of  relevant  size 
for  practical  security  typically  execute  on  the  order  of  milliseconds. 

4.3. 1.2  Notation. 

For  a  set  S,  the  notation  x  ^  S  means  that  the  element  v  is  selected  randomly  from  S 
according  to  a  uniform  distribution.  For  two  integers  a,  b,  the  notation  [a,  b]  represents  the 
s&t  {x  e  Z  :  a  <  X  <  b}.  Fet  G  be  a  finite  cyclic  group  and  G^  denote  the  set  of  generators 
of  G.  Fix  generators  Pi  6  G^  and  P2  &  The  discrete  logarithm  of  an  element  Q  6  G, 
to  base  P,  is  written  as  diogp  2  where  i  =  1,  2.  The  notation  Pi  ~  P2  indicates  that 
dlogpj(Pi)  =  dlogp2(P2)-  Elements  in  angle  brackets  represented  by  (...)  indicate  a  tuple 
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(an  ordered  list  of  elements),  while  braces  such  as  {...}  represent  a  set.  Functions  used 
throughout  this  chapter  are  shown  in  Table  4.1. 


Table  4.1:  Functions 


Function 

Definition 

depth(i) 

Returns  the  number  of  elements  in  the  label  i. 

indexir) 

Returns  the  index  of  the  access  policy  node  r.  The  children  of  a  node  are 

uniquely  indexed  from  the  set  [1,  ric]  where  ric  is  the  number  of  children. 

att(t) 

Returns  the  attribute  assigned  to  a  leaf  node  in  an  access  policy  or  the 

index  into  an  array  of  protected  attribute  ciphertexts. 

pindex(aHr) 

The  index  in  the  array  of  protected  attribute  ciphertexts  that  represents 

the  attribute  attr. 

parent(T) 

Returns  the  parent  node  in  an  access  policy  tree. 

MACk(A) 

The  result  of  executing  a  message  authentication  code  algorithm  on 

input  A  with  key  k. 

r(A) 

Similar  to  the  policy  satisfaction  algorithm  described  in  [17].  The 

function  takes  an  access  policy  P  and  a  key  structure  A  and  returns  a  set 

(possibly  empty)  of  labels  at  each  node  that  can  be  used  to  satisfy  the 

policy  at  that  node. 

4.3.2  MA-AHASBE  Overview. 

This  section  introduces  the  informal  mechanics  of  how  MA-AHASBE  operates.  This 
work  is  a  combination  of  two  previous  works,  LW-AHIBE  [89]  and  CP-ASBE  [17].  The 
goal  is  to  leverage  the  identities  from  the  AHIBE  scheme  as  protected  attributes  in  the 
CP-ASBE  scheme.  Since  the  attributes  are  not  fixed  during  system  setup,  MA-AHASBE 
system  would  be  considered  a  large  universe  system.  This  section  introduces  the  notions 
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of  attributes,  attribute  hierarchies,  policies,  and  key  structures  in  the  context  of  small, 
tangible  examples.  This  informal  description  is  intended  to  provide  intuition  for  the  formal 
definitions  provided  later  in  the  chapter. 

4.3.2. 1  Decentralization. 

In  order  to  provide  the  ability  to  work  with  different  authorities,  a  trusted  central 
authority  must  create  a  set  of  global  parameters.  The  global  parameters  scale  linearly  with 
the  number  of  users  in  the  system  since  they  contain  global  identifier  information  for  each 
user.  The  trusted  central  authority  can  be  replaced  by  any  decentralized  secure  multi-party 
computation  (SMPC)  protocol  that  supports  finite  field  arithmetic  and  random  number 
generation.  Furthermore,  the  results  of  the  computations  (global  identifiers)  are  all  made 
public  and  no  secret  information  from  the  global  setup  is  needed  for  any  other  computations 
(aside  from  generating  more  identifiers).  This  limits  the  need  for  the  SMPC  protocol  to  only 
computations  required  during  global  setup.  However,  depending  on  the  SMPC  protocol 
used,  further  considerations  must  be  made.  For  example,  SMPC  protocols  that  assume  a 
dishonest  majority  of  participants  often  cannot  simultaneously  support  robustness  to  node 
failure  (or  refusal  to  participate).  An  example  is  when  a  single  party  may  unilaterally 
halt  the  computation  process  if  it  chooses  to  stop  participating  in  the  protocol,  leaving 
the  remaining  members  unable  to  recover.  The  effect  on  a  decentralized  MA-AHASBE 
implementation  is  that  there  may  not  be  enough  global  identifiers  generated  when  the 
protocol  stops  executing  to  support  the  total  number  of  users  in  the  system.  One  way 
to  mitigate  this  is  to  pre-generate  enough  global  identifiers  during  global  setup  (and  not 
proceed  with  any  other  algorithms  until  global  setup  is  complete)  so  that  each  user  has  a 
unique  identifier  for  the  lifetime  of  the  system.  This  might  be  a  large  up  front  computational 
cost  if  there  are  a  large  number  of  users.  It  may  also  be  difficult  to  predict  a  priori 
either  the  total  of  number  users  the  system  will  support  or  even  the  system  lifetime  itself. 
This  particular  risk  could  be  mitigated  by  choosing  a  protocol  that  allows  fewer  dishonest 
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participants  but  provides  more  robustness  guarantees.  With  less  risk  of  the  protocol  halting 
due  to  a  small  number  of  participants,  members  of  the  SMPC  might  then  be  willing  to  use 
the  system  while  computing  the  identifiers  on-demand  as  new  users  join.  These  types  of 
tradeoffs  along  with  other  details  on  replacing  the  trusted  central  authority  with  an  SMPC, 
while  important  to  any  real  world  decentralized  deployment,  are  considered  orthogonal  to 
the  principal  design  of  MA-AHASBE  and  we  do  not  address  them  further  in  this  chapter. 

4.3.2. 2  MA-AHASBE  Fundamentals. 

MA-AHASBE  belongs  to  the  category  of  ciphertext-policy  attribute  based  encryption 
or  CP-ABE  and  therefore  has  notions  of  attributes  and  policies.  We  begin  by  describing 
attributes.  In  MA-AHASBE,  attributes  belong  to  an  attribute  hierarchy  which  is  represented 
as  a  tree.  Nodes  in  this  hierarchy  belong  to  one  of  four  categories:  global  parameter, 
authority  parameter,  domain,  and  leaf.  There  is  just  one  global  parameter  node  that 
represents  the  root  of  the  hierarchy.  The  immediate  children  of  the  global  root  node  must 
be  authority  parameter  nodes.  The  immediate  children  of  the  authority  parameter  nodes 
must  be  domain  nodes.  The  domains  that  are  immediate  children  of  authority  parameter 
nodes  are  called  top  level  domains.  Domains  may  have  either  domain  or  leaf  nodes  as 
children.  Nodes  without  any  children  are  leaf  nodes  and  leaf  nodes  must  be  children  of 
domain  nodes  (not  global  or  authority  parameter  nodes).  Attributes  in  MA-AHASBE  are 
fundamentally  identities  in  EW-AHIBE.  As  with  most  HIBE  systems,  the  attributes  are 
described  as  a  tuple  of  identities.  We  write  elements  of  the  tuple  as  strings  in  double 
quotations  (e.g.,  "University",  "Physics",  or  "Student")  and  the  tuple  itself  within  angle 
brackets  (e.g.,  ("University",  "Physics",  "Student")).  Often  when  written  as  a  tuple,  the 
double  quotes  are  dropped  from  the  individual  entries  (e.g.,  (University,  Physics,  Student)). 
The  order  of  the  elements  represents  a  path  along  the  attribute  hierarchy.  An  attribute  name 
is  fully  qualified  if  it  contains  the  path  from  a  global  parameter  node  to  a  leaf  node.  When 
the  context  is  clear,  an  attribute  will  usually  be  referenced  by  only  its  last  few  elements 
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(e.g.,  "Intern",  (Registrar,  Fail)).  When  the  elements  given  is  enough  to  uniquely  identify 
an  attribute,  the  attribute  is  ealled  inferentially  qualified.  Otherwise  the  attribute  is  ealled 
partially  qualified.  For  example,  in  Figure  4.1,  "Student"  is  partially  qualified  sinee  it 
eould  refer  to  the  attribute  in  either  the  "Physies"  or  "Eleetrieal  Engineering"  domain.  The 
attribute  referenees  (Physies,  Student)  or  "Intern"  are  inferentially  qualified. 


;  Authority  Parameters  1 
:  (Top  Level)  Domain 
Normal  Attribute 
I  Protected  Attribute  I 
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PHY220 

PHY440  TA  Professt 
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ENG321 

Student 


TA  Professor 


Eigure  4. 1 :  Eull  Attribute  Chart 


We  use  the  example  shown  in  Eigure  4. 1  throughout  this  seetion  whieh  represents  a 
hierarehy  of  attributes.  In  Eigure  4.1,  there  are  three  authority  parameter  nodes  that  eaeh 
share  the  same  global  parameter  root  node.  In  MA-AHASBE,  eaeh  global  and  authority 
parameter  node  is  uniquely  identifiable  (in  Eigure  4.1  the  global  identifier  is  G\  and  the 
authority  identifiers  are  Ai,  A2  and  A3).  Eaeh  authority  parameter  node  represents  an 
authority  in  the  system.  Examples  of  domain  nodes  inelude  "University"  (a  top  level 
domain),  "Registrar",  "Programs",  and  "Sparky".  Note  that  domains  ean  have  other  domain 
nodes  as  ehildren.  A  domain  is  also  referred  to  as  a  subdomain  of  its  parent.  In  the 
example,  "Government"  is  a  subdomain  of  the  authority  parameter  node  A3,  and  "Sparky" 
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is  a  subdomain  of  "Programs".  The  depth  of  the  hierarehy  is  defined  to  be  the  length  of 
the  longest  path  from  an  authority  parameter  node  to  a  leaf  node.  For  example,  the  depth 
of  the  hierarehy  shown  in  Figure  4.1  is  4  (see  for  example  the  path  (A3,  "Government", 
"Programs",  "Sparky",  "General  Aeeess")).  Finally,  Figure  4.1  shows  a  special  type  of  leaf 
node  called  a  protected  node.  These  nodes  are  used  when  the  attribute  itself  is  sensitive  to 
disclosure  and  will  be  discussed  in  greater  detail  next  when  we  discuss  policies. 

Policies  in  MA-AHASBE  follow  the  same  mechanics  as  those  in  CP-ASBE.  The 
policy  is  a  tree  of  policy  nodes  where  each  leaf  node  represents  an  attribute  and  each  non¬ 
leaf  node  acts  as  a  threshold  node.  The  threshold  indicates  how  many  children  nodes  must 
be  satisfied  in  order  to  satisfy  that  particular  node’s  policy.  The  threshold  tis  a  value  in  the 
range  [1,  ric]  where  is  the  number  of  children  nodes.  A  threshold  of  1  is  equivalent  to 
an  OR  operation  and  a  threshold  equal  to  ric  is  equivalent  to  an  AND  operation.  The  most 
straightforward  policies  are  those  where  all  the  attributes  come  from  the  same  domain. 
Such  a  policy  is  shown  in  Figure  4.2. 


Gi 

1 


(University,  Physics) 
2 


Figure  4.2:  Example  policy  with  attributes  from  a  single  domain 
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Policies  consist  of  four  types  of  nodes  that  play  similar  (though  not  identical)  roles 
as  attribute  hierarchy  nodes.  They  are  global,  authority,  domain,  and  leaf.  Policies  can 
contain  multiple  global  nodes,  however,  there  is  typically  only  one.  All  global  nodes  must 
all  have  the  same  label,  though  they  can  have  different  threshold  values.  The  immediate 
children  of  global  nodes  must  be  either  global  nodes  or  authority  nodes.  Authority  nodes 
are  labeled  according  to  their  corresponding  identifier  in  the  attribute  hierarchy.  The 
immediate  children  of  authority  nodes  are  domain  nodes.  In  contrast  to  the  domain  nodes 
in  an  attribute  hierarchy,  domain  nodes  in  policies  are  inferentially  qualified  references 
(implicitly  prepended  with  the  label  of  their  authority  node  parent)  beginning  with  a  top 
level  domain  and  ending  with  the  domain  that  contains  the  relevant  attributes.  Finally, 
leaf  nodes  represent  attributes.  In  order  to  satisfy  the  policy  such  as  the  one  shown  in 
Figure  4.2,  a  user  must  present  attribute  keys  that  satisfy  each  node  starting  from  the  leaf 
nodes  and  proceeding  up  the  policy  to  the  root  node.  A  leaf  node  is  satisfied  if  the  owner 
possesses  a  key  for  that  attribute.  Note  that  in  Figure  4.2,  since  the  domain  is  inferentially 
qualified,  the  attribute  names  have  been  abbreviated  since  their  lineage  in  the  hierarchy  can 
also  be  inferred.  The  policy  node  named  "Student"  in  Figure  4.2  would  correspond  to  the 
attribute  (Gi,  Ai,  University,  Physics,  Student)  (and  not  the  similarly  named  attribute  (Gi, 
Ai,  University,  Electrical  Engineering,  Student)  from  Eigure  4.1).  In  Eigure  4.2,  we  see 
that  the  user  only  needs  to  satisfy  one  of  the  policy  nodes  "Student",  "TA",  or  "Professor". 
This  is  an  example  of  the  OR  operation,  since  possession  of  only  a  single  attribute  satisfied 
the  threshold  requirements.  By  meeting  this  threshold,  the  policy  node  labeled  "1"  is  now 
satisfied.  The  domain  node  labeled  "(University,  Physics)"  however  requires  both  of  its 
children  to  be  satisfied.  The  right  child  "1"  provides  one  satisfied  child  node.  In  order  to 
meet  the  threshold  of  two,  the  user  must  also  satisfy  the  node  labeled  "PHY220".  The  user 
must  of  course  have  a  key  corresponding  to  the  attribute  (University,  Physics,  PHY220) 
in  order  to  satisfy  this  node.  If  this  is  the  case,  then  the  "Physics"  node  is  satisfied.  The 
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authority  node  "Ai"  and  the  root  node  "Gi"  are  then  satisfied  in  turn  sinee  eaeh  only  has  a 
threshold  of  one.  Onee  the  root  node  is  satisfied,  the  poliey  eorresponding  to  the  tree  is  also 
eonsidered  satisfied.  A  formal  deseription  of  the  poliey  satisfaetion  algorithm  ^(A)  ean  be 
found  in  [17]. 

In  MA-AHASBE,  the  aeeess  poliey  is  explieitly  bundled  in  plaintext  with  the 
eiphertext.  This  is  neeessary  beeause  the  strueture  of  the  eiphertext  mirrors  the  strueture 
found  in  the  poliey,  so  the  deerypting  party  must  have  aeeess  to  the  poliey  in  plaintext  in 
order  to  determine  whieh  keys  to  apply  to  whieh  loeations.  For  many  use  eases,  this  is  not 
a  problem  sinee  the  aeeess  poliey  itself  is  often  not  sensitive  information.  However,  it  may 
be  the  ease  that  eertain  attributes  are  sensitive  and  should  not  be  made  publie. 
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Figure  4.3:  Example  poliey  with  a  proteeted  attribute 


Consider  the  poliey  shown  in  Figure  4.3.  This  enforees  a  poliey  where  the  user  must 
have  either  the  "General  Aeeess"  or  "Speeial  Aeeess"  attributes.  Here,  the  knowledge 
that  a  "Speeial  Aeeess"  attribute  exists  under  the  domain  "Sparky"  is  eonsidered  sensitive. 
The  attribute  (Government,  Programs,  Sparky,  Speeial  Aeeess)  should  not  be  allowed  in 
plaintext  polieies.  MA-AHASBE  deals  with  this  issue  in  one  of  two  ways  depending  on 
the  nature  of  the  proteeted  attribute.  The  first  ease  applies  when  the  proteeted  attribute  ean 
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itself  be  protected  under  a  policy  which  does  not  contain  sensitive  attributes.  For  example, 
perhaps  any  user  with  the  attribute  (Corporation,  Human  Resources,  Supervisor),  which 
is  not  sensitive,  is  allowed  to  know  about  the  "Special  Access"  attribute  for  the  Sparky 
program  (even  if  they  don’t  actually  possess  the  "Special  Access"  attribute).  This  can  be 
done  by  creating  another  ciphertext  that  encrypts  the  plaintext  "(Government,  Programs, 
Sparky,  Special  Access)"  under  a  policy  that  does  not  have  any  protected  nodes  (in  the 
example  just  given,  this  policy  would  require  the  "Supervisor"  attribute).  A  reference  can 
then  be  made  to  this  ciphertext  from  the  position  of  the  protected  node  in  the  original  policy. 
We  call  the  referenced  policy  an  explicitly  referenced  protection  policy.  During  decryption, 
if  the  user  satisfies  the  reference  policy  they  can  then  determine  the  name  of  the  original 
protected  attribute,  thereby  recovering  the  original  policy. 

This  technique  for  protecting  attributes  is  not,  for  lack  of  better  words,  entirely 
satisfying.  It  is  not  difficult  to  imagine  a  scenario  where  a  sensitive  attribute  cannot  be 
protected  through  only  attributes  which  are  not  sensitive.  For  example,  perhaps  only  users 
who  possess  the  "Special  Access"  attribute  are  allowed  to  know  about  the  attribute  "Special 
Access".  To  address  this  challenge,  we  fall  back  on  the  anonymity  property  of  LW-AHIBE. 
For  a  formal  definition  of  anonymity  in  LW-AHIBE,  see  [89].  Informally,  anonymity  in 
LW-AHIBE  means  that  a  ciphertext  does  not  reveal  any  information  about  the  identity 
used  to  create  it,  except  potentially  to  a  user  who  possesses  the  private  key  for  the  relevant 
identity.  This  latter  caveat  is  necessary  since  a  user  in  possession  of  the  appropriate 
key  could  simply  attempt  to  decrypt  and  determine  if  the  result  contained  meaningful 
information.  We  leverage  anonymity  by  initially  proceeding  in  a  manner  similar  to  the 
method  described  above.  However,  instead  of  creating  a  regular  ciphertext,  a  ciphertext 
is  created  based  on  a  fixed,  single  attribute  policy.  This  policy  contains  only  the  protected 
attribute,  and  the  plaintext  message  contains  some  type  of  readily  identifiable  message  such 
as  a  numeric  index  or  a  cryptographic  hash  of  the  attribute  name.  Note  that  for  this  reference 
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ciphertext,  the  plaintext  used  to  ereate  the  eiphertext  is  not  what  is  being  proteeted,  but 
rather  the  poliey  (and  therefore  the  attribute)  used  to  ereate  it.  Now,  instead  of  explieitly 
ineluding  this  fixed,  single  attribute  poliey  with  the  eiphertext,  it  is  not  ineluded  at  all. 
Rather  it  is  implied  through  the  faet  that  the  only  way  to  determine  the  attribute  used  in  the 
poliey  (whieh  reeall  are  really  identities  in  LW-AHIBE)  is  to  perform  a  deeryption  using 
the  appropriate  attribute  key.  We  eall  this  type  of  poliey  an  implicitly  referenced  protection 
policy. 

Proteeting  attributes  by  using  implieitly  refereneed  proteetion  polieies  ereates  an 
additional  eomputational  eost  to  the  deerypting  party.  The  seenario  is  not  too  different  from 
having  a  key  ring  full  of  labeled  keys  and  a  number  of  unmarked  loeked  doors.  Without 
knowing  whieh  key  goes  to  whieh  door,  the  user  has  to  try  eaeh  key  with  eaeh  door  until 
a  mateh  is  found.  If  a  mateh  is  found,  we  ean  now  label  the  door  aeeording  to  the  label 
of  the  key  that  unloeks  it.  In  MA-AHASBE,  the  keys  are  the  attributes  the  user  possesses, 
and  the  doors  are  the  proteeted  attributes  in  a  poliey  (proteeted  through  implieit  proteetion 
polieies).  The  time  required  to  attempt  to  deerypt  a  single  proteeted  attribute  with  a  single 
attribute  key  is  0(1).  The  poliey  tree  has  a  fixed  size  (it  only  eontains  one  attribute)  and  a 
single  attempt  to  deerypt  ean  immediately  be  determined  to  be  sueeessful  or  not  (with  high 
probability)  sinee  the  reeovered  plaintext  should  have  some  elear  meaning.  Eaeh  attempt 
also  only  uses  a  single  attribute  key  (sinee  only  one  key  is  neeessary  to  satisfy  the  poliey). 
If  there  are  m  proteeted  attributes  in  a  poliey  and  the  user  possesses  n  keys,  the  total  number 
of  attempts  is  0(m  *  n).  This  eould  still  be  impraetieal  depending  on  the  eonstants  (e.g., 
time  required  per  attempt,  m,  n),  though  we  expeet  that  in  praetieal  usage  the  number  of 
proteeted  attributes  in  a  poliey  (m  <  10)  and  number  of  total  keys  (n  <  100)  to  be  relatively 
small.  It  is  important  to  note  that  this  key  diseovery  proeess  is  distinet  from  and  oeeurs 
before  the  regular  deeryption  algorithm.  This  teehnique  is  admittedly  not  as  elegant  as  other 
attribute  proteetion  meehanisms  sueh  as  those  found  in  inner  produet  type  systems  [69]. 
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However,  we  feel  that  the  other  aspects  of  MA-AHASBE  make  it  a  better  overall  fit  for  the 
enterprise  requirements  discussed  earlier  and  that  the  performance  of  protecting  attributes 
this  way  is  still  within  the  limits  of  practicality.  Note  that  this  additional  computation  is 
not  incurred  when  attributes  are  protected  using  explicitly  referenced  protection  policies. 
In  that  case,  the  original  policy  is  recovered  (or  determined  to  be  irrecoverable)  in  a  direct 
manner  that  does  not  depend  on  the  number  of  keys  or  the  number  of  protected  attributes. 

4.3.2. 3  Key  Structures,  Attribute  Sets  and  Multiple  Domain  Policies. 

So  far  we  have  only  discussed  the  most  straightforward  use  of  attributes  in  MA- 
AHASBE,  single  attributes  from  a  single  domain.  MA-AHASBE  also  supports  compound 
attributes  in  the  form  of  attribute  sets,  and  the  capability  to  mix  and  match  attributes 
from  multiple  domains  and  multiple  authorities  within  the  same  policy.  As  the  leaves  of 
the  policy  inherit  their  design  from  EW-AHIBE,  the  methodology  for  combining  policy 
nodes  to  satisfy  a  policy  is  inspired  by  CP-ASBE.  The  reader  unfamiliar  with  CP-ASBE 
is  encouraged  to  review  [17]  for  a  more  detailed  exposition  of  its  merits.  Essentially,  CP- 
ASBE  offers  the  capability  to  combine  singleton  attributes  into  compound  attributes,  while 
giving  the  encrypting  party  the  choice  of  allowing  such  compound  attributes  to  be  split 
back  apart  in  order  to  satisfy  the  policy.  This  becomes  useful  for  representing  complex 
attributes  that  naturally  occur  in  access  control  policies,  but  are  difficult  to  implement  as 
singletons.  Also  it  provides  a  rather  elegant  way  of  allowing  numerical  attributes  with 
numerical  comparisons  in  policies.  Einally,  it  also  allows  for  an  efficient  key  revocation 
methodology. 

Attribute  sets  work  by  combining  attributes  keys  into  recursive  sets.  These  recursive 
sets  are  called  key  structures.  A  key  structure  is  issued  to  a  specific  user  by  a  domain. 
Most  commonly,  it  only  contains  attributes  from  the  issuing  domain,  however  it  may 
contain  attributes  from  other  domains  within  the  same  authority.  Each  user  in  the  system  is 
associated  with  a  global  identifier.  This  identifier  allows  multiple  authorities  and  domains 
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{Authority,  Domain,  IDi) 


/  \ 

F  G 

Figure  4.4:  Example  key  structure 


to  issue  keys  to  a  single  user.  It  also  prevents  users  with  different  identifiers  from  colluding 
to  satisfy  policies  they  could  not  satisfy  on  their  own.  When  a  user  possesses  key  structures 
from  multiple  domains,  the  set  is  called  a  key  ring.  An  example  key  structure  is  shown  in 
Figure  4.4.  Here  we  see  that  it  is  a  tree  structure  with  three  types  of  nodes:  a  root  node,  leaf 
nodes  and  set  nodes.  The  root  node  indicates  the  authority  and  domain  that  generated  the 
structure  as  well  as  the  global  identifier  associated  with  the  key  structure.  The  child  of  the 
root  node  is  a  set  node.  Set  nodes  can  have  as  children  either  leaf  nodes  or  set  nodes,  while 
leaf  nodes  have  no  children.  In  addition  the  set  nodes  have  been  labeled  in  a  particular  way. 
The  label  [e]  represents  an  empty  label  and  the  root  set  node  (the  child  of  the  root  node)  is 
given  the  empty  label.  Then  the  set  nodes  that  share  a  parent  are  numbered  starting  with  1. 
This  number  is  then  appended  to  the  label  of  the  parent  to  form  the  label  of  the  child.  The 
leaf  node  children  of  a  set  node  implicitly  belong  to  a  set  whose  label  is  made  by  appending 
0  to  the  label  of  the  parent  set  node.  This  special  set  is  called  an  outer  set.  For  example,  in 
Figure  4.4  the  leaf  nodes  { A,  B,  C}  belong  to  an  outer  set  A[o]  and  {F,  G}  belong  to  A[ij^o]- 
Finally,  the  depth  of  a  set  is  determined  by  the  number  of  elements  in  its  label,  ignoring 
any  final  zero  entries.  For  example,  both  Aj^j  and  A[o]  have  depth  0,  A[i]  has  depth  1,  and 
A[ij^0]  has  depth  2. 
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By  default,  a  policy  in  MA-AHASBE  can  only  be  satisfied  with  leaf  node  children  of 
a  particular  set  node.  In  other  words,  all  the  attributes  used  to  satisfy  a  policy  must  belong 
to  the  same  outer  set.  This  is  what  enables  single  attributes  to  form  compound  attributes. 
For  example,  in  Figure  4.4  the  attributes  D  and  E  form  a  compound  attribute.  In  this  case, 
without  any  other  conditions,  a  user  with  the  key  structure  shown  in  Figure  4.4  could  not 
satisfy  a  policy  that  required  both  A  and  D  since  they  belong  to  different  outer  sets.  On  the 
other  hand,  the  same  user  could  satisfy  a  policy  that  only  required  A  or  only  required  D. 
The  user  could  also  satisfy  a  policy  that  required  both  D  and  E,  since  they  both  belong  to  the 
same  outer  set.  In  this  way,  outer  sets  like  {A,  B,  C}  or  {H,  1, 1}  form  compound  attributes 
that  can  only  be  used  together  and  cannot  by  default  be  mixed  and  matched  piecemeal  with 
other  compound  attributes.  In  a  sense  this  can  be  seen  as  a  generalization  of  traditional 
attribute  based  encryption  systems.  In  that  case,  all  of  the  attributes  in  the  system  belong 
to  the  top  most  outer  set  (i.e.,  they  form  one  large  compound  attribute). 

One  way  to  visualize  the  policy  satisfaction  algorithm  is  to  imagine  assigning  the 
label  of  the  outer  set  used  to  satisfy  any  particular  leaf  node  to  that  leaf  node.  Threshold 
nodes  can  only  combine  children  nodes  that  have  been  satisfied  with  the  same  label.  While 
this  certainly  prevents  mixing  singleton  attributes  that  belong  to  compound  attributes,  it 
also  prevents  multiple  compound  attributes  from  being  used  in  the  same  policy.  Figure 
4.5(a)  shows  a  policy  that  uses  attributes  from  different  sets.  Assuming  the  key  structure 
in  Figure  4.4,  the  user  can  satisfy  either  the  left  branch  or  the  right  branch,  but  not  both. 
This  is  because  the  label  of  the  left  node  (in  this  case  [0]  since  the  attributes  that  satisfy 
the  relevant  leaf  nodes  come  from  the  outer  set  A[o])  does  not  match  the  label  of  the  right 
child  node  (which  is  [1,0]  from  the  outer  set  A[i  o]).  For  the  policy  in  Figure  4.5(a),  it  is  not 
required  to  satisfy  both.  However,  if  the  root  node  threshold  was  changed  to  2  as  in  Figure 
4.5(b)  the  policy  cannot  be  satisfied  with  the  key  structure  in  Figure  4.4. 
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Figure  4.5:  Example  polieies  with  translation  nodes 


Attribute  sets  also  allow  polieies  to  eontrol  how  eompound  attributes  can  be  combined 
with  each  other.  The  mechanism  for  this  control  is  called  a  translation  node.  Translation 
nodes  allow  users  to  translate  attributes  in  their  key  structures  from  one  depth  to  another. 
Figure  4.5(c)  shows  how  a  translation  node  might  look  in  a  policy.  The  translation  nodes 
have  been  labeled  "1  ^  0".  This  means  that  if  the  child  node  of  the  translation  node  was 
satisfied  using  an  outer  set  at  depth  1,  the  translation  node  is  considered  to  be  satisfied  by 
the  label  of  the  parent  of  that  outer  set  which  itself  is  at  depth  0.  For  an  example  we  use  the 
policy  Figure  4.5(c)  and  the  key  structure  in  Figure  4.4.  Here,  the  leaf  node  "D"  can  only 
be  satisfied  by  the  outer  set  A[i  o]  which  has  depth  1.  The  translation  node  translates  the 
label  of  this  outer  set  to  its  parent  which  is  A[0].  The  translation  node  now  can  be  combined 
with  other  nodes  that  have  been  satisfied  with  A[o]  such  as  "A",  "B"  and  "C".  The  same 
process  applies  to  "E".  The  policy  in  Figure  4.5(c)  represents  how  a  compound  attribute 
can  be  split  back  into  singletons  and  combined  with  other  attributes.  Figure  4.5(d)  gives 
an  example  of  using  multiple  compound  attributes  within  the  same  policy,  but  not  allowing 
the  compound  attributes  to  be  split  apart.  Note  that  the  threshold  has  to  be  met  first,  and 
then  the  result  is  translated.  Unlike  the  policy  in  Figure  4.5(b),  the  policy  in  Figure  4.5(d) 
can  be  satisfied  by  the  key  structure  in  Figure  4.4. 
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Figure  4.6:  Example  policy  with  multiple  authorities  and  domains 
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Figure  4.7:  Example  key  ring 
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To  see  an  example  of  how  attribute  sets  ean  be  utilized  with  multiple  authorities  and 
domains,  we  take  an  additional  example  from  Figure  4.1.  Say  that  we  want  to  ereate  a 
policy  that  restricts  access  to  those  interns  in  Corporation’s  Internship  Program  who  have 
passed  PHY220  and  have  either  passed  or  audited  ENG321.  Such  a  policy  is  shown  in 
Figure  4.6  and  a  key  ring  that  will  satisfy  this  policy  is  shown  in  Figure  4.7.  The  key 
ring  shows  that  the  attributes  for  the  course  have  been  combined  into  an  attribute  set.  This 
makes  it  so  that  a  policy  can  be  created  that  prevents  a  user  from  applying  a  (Pass)  attribute 
from  one  course  to  another.  For  the  policy,  we  include  an  extra  translation  node  beneath 
two  of  the  domains.  In  a  multiple  domain  policy,  each  domain  node  must  have  a  label  of 
depth  0  in  order  to  combine  with  other  domains.  Since  the  (Intern)  attribute  is  already  at 
depth  0  in  the  key  ring,  it  does  not  require  a  translation  node. 

4.3.3  Algorithm  Summary. 

The  following  algorithms  define  a  multi-authority,  hierarchical,  attribute-set  based 
encryption  system: 

GlobalSetup(/l,  tiuser)  GP  The  global  setup  algorithm  takes  in  a  security  parameter 
A  and  the  number  of  users  riuser  the  system  must  support.  It  outputs  the  public  global 
parameters  GP  for  the  system. 

AuthoritySetup(GP)  ^  MS K^,  AP^  Each  authority  runs  the  authority  setup  algorithm 
with  the  global  parameters  GP  and  produces  a  master  secret  key  MS  Ka  and  some 
public  authority  parameters  APa  for  an  authority  A. 

DomainKeyGeneration(GP,  MSKa,  APa,  I'Ddomain  =  (idi,  ...,idf),  h')  DSKori.  An 
authority  can  create  domains  that  may  in  turn  create  further  subdomains  or  issue  user 
secret  keys  (US K).  The  term  h'  determines  how  many  levels  of  delegation  are  al¬ 
lowed  by  the  key.  Domain  names  are  represented  as  a  tuple  of  identities  correspond¬ 
ing  to  a  path  in  an  attribute  hierarchy  where  idi  represents  a  top  level  domain. 
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Delegate(GP,  DSKorUSK,  APa,  IDdomainOr IDattr  =  (idi, id^),  id^+i,  h') 


DS  KorUSKorl.  When  used  with  a  DS  K  and  I'D  domain  as  input,  this  algorithm 
outputs  the  DSK  for  a  subdomain.  The  term  h'  determines  how  many  levels  of 
delegation  are  allowed  by  the  key.  When  used  with  a  US  K  and  I  Dam  as  input,  the 
algorithm  outputs  another  US  K  that  represents  an  attribute  that  has  been  extended 
one  level  to  a  commitment  value  created  during  encryption. 

UserKeyGeneration(G/’,  DSK,  A,  IDuser)  US K  This  takes  as  input  a  domain’s 
secret  key,  a  unique  global  identifier  for  a  user,  and  the  key  structure  for  that  user 
A  (i.e.,  the  attributes  that  have  been  assigned  to  them)  and  generates  a  user  secret 
key. 

Encrypt(GP,  [APa,  APb,  ...},  A1)  ^  CT  This  encrypts  a  message  A1  under  an  access 
policy  V  with  attributes  controlled  by  authorities  [A,  B,  ...}. 

DecryptCGP,  CT,  US K)  ^  Mor ±  Decrypts  a  ciphertext  and  produces  a  message  if 
the  decryption  is  successful.  If  decryption  is  not  successful,  it  returns  the  special 
symbol  -L. 

4.4  MA-AHASBE  Construction 

GlobalSetup(/l,  riuser)  GP  Let  Gi,  G2  and  Gj  be  groups  of  the  same  prime  order 
p.  Let  e  :  Gi  x  G2  ^  Gr  be  an  asymmetric  bilinear  map.  Let  IDuser  =  (id„ier) 
where  \duser  e  Choose  random  generators  Pi  e  Gi  and  F2,  Qm,  Utd  e  G2.  Let 
HidilDuser)  =  ^^userQid  +  U id-  The  parameter  Uuser  is  the  total  number  of  users  in  the 
system  that  require  a  globally  unique  identifier.  Let  {IDuser.j]ie[i,nuseA  of  ^ii 

user  identifiers  in  the  system.  Note  that  Qid  and  [/,y  are  fixed  and  that  the  number  of 
elements  in  [IDuser.j)  is  Uuser-  Let  r^ax  denote  the  maximum  recursion  depth  for  the 
CP-ASBE.  Choose  ag,/3id,  {y3,}is[o,w]  ^  ff  tho  global  authority  needs  to  generate 
additional  identifiers  after  setup,  then  it  must  retain  the  global  secret  key  GSK.  Let 
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•K  :  {0, 1}*  ^  {0, 1}^  be  a  cryptographic  hash  function.  Let  h  :  {0, 1}*  ^  {0, 1}"^  be  a  hash 
function  from  a  family  of  pairwise  independent  hash  functions.  If  d  =  128,  then  per  the 
analysis  in  [19]  the  size  of  the  input  space  of  h  should  be  448  bits. 


GP:  (p,  e,  Pi,  h,  P^,  F2,  ^^2,  {PiPi,jF2)m,r„,^A^e{Pi,F2r 


{JD, 


user:  j 


'^p,Fiid(FF)user:j),  j^Fiid(F F)user:j),  -^Fiid(F F)user:j),  ]^P(id{I iDuser.j)] je[\,nu,„d 


do 


da  ' 


AuthoritySetup(GP)  ^  MS  K^,  AP^  Let  h^ax  denote  the  maximum  depth  of  the  dele¬ 
gation  hierarchy.  Choose  a  random  generator  P2  e  G2;  elements  {Qij} je[i,hmax]’  Ui  ^  Gi 
and{22j}2g[i,/i„,,],  U2  ^  G2  such  that  (Qij  ~  22,;);6[i,ft™,]  and  t/i  ~  U2.  Choose  qa,  a,  v, 
v'  ^  Z*.  Set  y2  =  VF2,  V2  =  v'F2  and  t  =  v  -1-  av'  so  that  TF2  =  1^2  +  aV^. 


APa:  (aPi,  tPi,  Ui,  aUi,  tUi,  {Qii,aQii,TQ 


'A,j)je[l,h 

maxi  ’ 


V2,V'e(P,,P2D 


MSKa-  (aA^2,  {Q2,j]je[l,h„,^,p  U2) 

DomainKeyGeneration(G/’,  MSKa,  APa,  IDdomain  =  (idi, ...,  id^),  h')  DSKor±  If 
h'  i  [£  +  2,hmax  -  2],  then  return  ±.  Otherwise,  choose  wi,  W2,  n,  r2,  r^,  r4,  (zij, 

Z2,j)je[£+l,h']  ^  Fei'H2{I D domain)  =  (Z  id222j)  +  t^2- 


Fdomain  • 


^1,1  =  W1P2  +  f  1^25 

K,,2  =  gV', 

^1,3  =  f \E2 

K2A  =  0:aP2  +  W\P{2{IiD  domain)  +  ^2^2, 

K2,2  =  GV', 

K2,3  =  GF’2 

■J\A  —  W2P2  +  0^2» 

Ji,2  = 

■^1,3  =  G'f’2 

J2A  —  ^2Ei2(,E D domain)  “1“  ^4^2, 

T-'_.  '  —  r  /y  .  -1  7/n 

72,2  =  ^^2, 

■^2,3  =  GF’2 

For  j  6  [^+  l,h'] 

DjA  =  W1Q2J  +  Z1JV2,  Dj2  =  Z1JV2,  Dj2  =  Z1JF2 

EjA  =  W2Q2,j  +  Z2,j^2,  Ej2  =  Z2jF2,  E  =  ZajFa 
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Delegate(GP,  DS KdomatnOrUS K,  APa,  IDdomainOr IDattr  =  (idi,  id^+1,  h') 

DSKorUSKor±  If  h'  i  [^+ then  return  J..  Otherwise,  choose  Wj,  /"p 
Tj,  r^,  {z\  j,  Z2j)je[U2,h']  ^  Notc  that  the  algorithm  performs  the  same  operations  for 
both  DSK  and  USK  inputs.  For  DSKdomain  input,  the  output  is  DS  K subdomain-  For  USK 
input,  the  output  is  . 


DSK 


subdomain 


or 


K, A +w\Ju+r[V2 


Ki,2^K,A+w[J,a  +  r[V^ 


K\a  ^  Ki2  +  w\JiA  +  r[F2 
7ij  <— +  r'y2  -^2,1 

■^1,2  ^  >^2'^1,2  +  ^3^2  ^2,2 

Jl,3  ^  W2J1A  +  ^3-^2  J2,3 

For  je[{  +  2,  h'] 


K2,i  K2A  +  idf+iZ)f+i4  +  Wj(72,i  +  idf+i£'^+i,i)  +  r2V2 

K2,2  ^  K22  +  idf+iZ)f+i,2  +  w\{J2,2  +  idf+l£'^+l,2)  +  ^2^2 

K2,3  ^  ^2,3  +  idf+lZ)f+l,3  +  w\{J2,3  +  idf+l£'f+l,3)  +  f^2^2 

■  ^2^2,1  +  id^+l^^+lj)  +  r'^V2 

■  ^2^2, 2  +  id^+l£'^+l,2)  +  r'^V2 

■  W2(J2,3  +  id^+l^f+l^)  +  Pa^2 


^  DjA+w\EjA+z\  jV2  Dj2  <-  Dj^2  +  w'iEj^2+z[  jV2  Dj^  <-  DjA  +  w[EjA  + 


z'E2 


Eja  <-  vv^^y.i  +Z2JV2 


E, 


7,2 


>^2^7,2 +4j^2 


Ej,3  ^  >^2'^y,3  +  z[  :E2 


UserKeyGeneration(GF,  DSK,  A,  ID  user)  USK  Here,  A  is  the  key  structure  is¬ 

sued  by  a  domain  with  IDdomam  =  (idi,...,id^)  for  a  user  with  a  global  identifier  IDuser  = 
(id„ie,-).  A  key  structure  contains  a  number  of  recursive  sets,  each  set  associated  with  a  re¬ 
cursive  depth.  A  set  in  A  is  labeled  with  an  integer  tuple  i,  where  the  number  of  elements 
in  i  corresponds  to  the  recursive  depth  of  the  set  and  each  element  of  i  comes  from  the  set 
[0, 00).  The  tuple  i  is  called  the  label  for  the  set  Ai.  The  notation  Kauthority,domain,user,i  fully 
qualifies  a  recursive  set  in  the  system,  though  we  generally  omit  all  but  the  tuple  portion 
for  convenience  and  use  the  simpler  notation  Ai  when  the  context  is  clear.  The  notation 
Ai^iij  represents  the  set  Ai  where  i  is  the  concatenation  of  i'  and  the  integer  j  6  [0, 00). 


57 


At  each  recursive  depth  d,  there  is  at  least  one  (possibly  empty)  set  Aj/yo  where  d  is  the 
number  of  elements  in  i'.  This  set  is  referred  to  as  the  outer  set  at  depth  d.  The  outer  set 
Ai'iio  contains  nk>0  number  of  attributes  such  that  Aj/yo  =  {3.\.\.'(ik]ke[i,nk]-  Note  that  A[o]  is 
the  outer  set  at  depth  0,  and  therefore  the  outer  set  for  all  of  P^authority,domain,user-  An  outer 
set  can  only  contain  attributes  and  cannot  contain  other  sets  (i.e.,  the  outer  set  itself  is  not 
recursive).  This  means  there  are  no  labels  where  the  last  two  elements  are  both  0. 

To  generate  a  user  key,  VAj  e  ^authority,domain,user,  Vattr  6  Aj  the  algorithm  calls 
Delegate(Z)S  A,  APa,  IJddomain,  idf+i  =  attr,  C  +  2)  and  stores  the  result  in  = 

^^7,(5’  •^y,5'  ^r+2,5’  ^/+2,c5^re[i.2],c5£[i,3] •  Then  the  algorithm  chooses  {rj  <  Z  p  ^V^i^^aiithor{tyAomain,use 
with  the  restriction  that  Vrj/yy  such  that  j  0  that  rj/yy  =  ri/yyyo.  The  algorithm  then  runs 
the  Restrict  ToUser(]K[g(j|.,  ID  user,  ^i)  algorithm  described  below  and  stores  the  result  in 

L^t  =  {IKj  attr  „^g;.}vattreA|- 


RestrictToUser(]K|g„^,  ID  user,  ^i)  ^  IKj^attr.i 


IK',  6  K'i,attr  :  A,,, 


I^A'i  +  riF2  +  r^o^HidilDuser) 
V/;,  6  K'i,a„r  :  Jy,6  ^  J'y^s 

'^^£+2,6  ^  ^'tattr  :  £>r+2,a  ^  D',^2,6 

'^^£+2,6  ^  :  A^+2,<5  E',^2,d 


if  y  I  2, 6  I  1 
if  7  =  2,  d  =  1 


Essentially,  RestrictToUser  appends  two  additional  components  onto  the  A2,i  portion 
of  the  key  in  the  input  set.  These  two  elements  are  critical  in  that  they  create  additional 
blinding  factors  during  decryption  that  provide  certain  security  protections.  How  these 
elements  work  will  be  described  in  more  detail  in  the  decryption  algorithm.  The  value  rj 
acts  as  a  label  for  the  attribute  set.  The  method  described  here  requires  that  the  attributes 
being  combined  into  a  set  originate  from  the  same  domain.  This  can  be  extended  to 
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other  domains  within  the  same  authority  (but  not  domains  from  different  authorities)  if 
domains  are  willing  to  share  these  labels.  The  details  of  this  extension  are  not  described 
in  this  chapter.  Finally,  the  user  key  US K  is  defined  as  follows: 


USK: 

VA;  G  ^authority, domain,user  • 

Kid  =  ^nHidil^user) 

V  _  TT  V  _  ““s’’"'':*)]  rTmt  \ 

- F2,Kid^0]  -  — - riidi-L  Uuser) 

Vriiij  such  that  j  0,  let  d  =  depth(i  ||  j)  where  d  >  i 

V  _  “''i||0+''l||j  17 

^^■2,iiiy  -  — ^ 


Pd 


Encrypt(GF,  {APa,  APb,  ...},  M)  CT  The  general  mechanism  for  generating  each 
node  is  very  similar  to  the  CP-ASBE  system.  The  primary  difference  is  that  the  generated 
ciphertext  reflects  the  multi-authority  and  AHIBE  enhancements  to  the  underlying  sys¬ 
tems.  To  support  multiple  authorities,  we  introduce  the  notion  of  global  nodes.  Global 
nodes  can  be  either  global  threshold  or  global  leaf  nodes.  A  global  leaf  node  marks  the 
root  of  a  subtree  where  all  the  nodes  in  the  subtree  belong  to  a  single  authority.  Global 
leaf  nodes  also  act  as  threshold  nodes,  and  therefore  have  an  associated  threshold  value. 
Global  threshold  nodes  work  in  the  same  way  as  local  threshold  nodes,  except  that  the 
children  of  a  global  threshold  node  must  be  global  (either  leaf  or  threshold)  and  the  par¬ 
ent  must  be  a  global  threshold  node  (or  no  parent  in  the  case  of  the  global  root  node). 
Also,  we  introduce  the  notion  of  a  domain  threshold  node.  When  a  policy  contains  leaf 
nodes  from  different  domains  within  the  same  authority,  there  must  be  a  threshold  node 
such  that  all  nodes  in  the  associated  subtree  all  come  from  the  same  domain.  Since  a 
global  leaf  acts  as  threshold  node,  a  global  leaf  node  can  fulfill  the  role  of  the  domain 
threshold  node  in  the  case  where  the  policy  only  uses  a  single  domain  from  the  relevant 
authority.  Otherwise,  an  additional  local  threshold  node  must  be  in  the  policy  to  act  as 
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the  domain  threshold  node.  When  this  additional  node  is  required,  then  it  is  always  the 
child  of  a  global  leaf  node.  The  children  of  a  domain  threshold  node  are  either  local  leaf 
or  local  threshold  nodes. 

The  encryption  begins  in  a  top  down  manner,  starting  with  a  global  root  node.  At 
each  node,  a  polynomial  qr  is  generated  for  all  nodes  (global  and  local)  and  a  similar 
polynomial  gr  is  generated  for  all  global  nodes.  For  each  threshold  node  r  in  the  tree,  the 
degree  dr  of  both  polynomials  qr  and  gr  are  set  to  be  one  less  than  the  threshold  value 
kr  (i.e.  dr  =  kr  -  1).  The  degree  of  a  local  leaf  node  is  0.  For  the  global  root  node 
R,  the  algorithm  chooses  a  random  5  4^  Z*  and  sets  ^r(O)  =  5  and  g^CO)  =  1.  From 
this  point  onward,  all  calculations  for  both  qr  and  gr  are  performed  in  the  exact  same 
manner.  The  only  difference  would  be  that  the  root  values  for  q  and  g  are  different  {s 
and  1  respectively).  The  calculations  are  explained  in  terms  of  q.  The  algorithm  chooses 
Jr  other  points  randomly  to  define  the  polynomial  qR.  For  any  other  threshold  node  r, 
it  sets  ^r(O)  =  dparent(T)(.index{T))  and  chooses  dr  other  points  randomly  to  completely 
define  qr.  Here  parent(T)  represents  the  parent  node  of  r.  Let  W  represent  the  global 
leaf  nodes  of  the  access  tree.  Y  represents  the  local  leaf  nodes,  and  X  represents  local 
translation  nodes.  represents  the  translation  indices  that  are  allowed  at  a  translation 
node.  Their  use  will  be  explained  in  the  decryption  algorithm.  Let  V  represent  the  set  of 
domain  threshold  nodes. 

Let  Kp  indicate  the  set  of  attributes  that  the  encryptor  wishes  to  keep  anonymous 
and  let  Up  represent  the  number  of  attributes  in  Kp.  The  function  pindex{3.\.\x)  returns  a 
unique  index  from  [1,  Up]  for  each  attribute  in  Kp.  The  algorithm  AttributeEncrypt  is 
the  same  algorithm  as  Encrypt  with  a  fixed  access  policy  of  a  single  attribute.  Also,  for 
AttributeEncrypt  the  access  policy  is  not  included  in  the  resulting  ciphertext. 

Let  IGylf  be  the  number  of  bits  required  to  represent  an  element  of  Gr.  Let  m  4— 
{0,  be  the  input  message.  Choose  x  4^  {0,  such  that  me  +  X{  <  If  the 
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message  is  a  symmetric  key  (or  the  seed  of  a  pseudorandom  number  generator),  the  rec¬ 
ommended  values  [19]  for  128-bit  security  are  =  128,  =  448.  Let  k'  ^  Gt-  Let 

[{0, 1}*]”  represent  the  first  n  bits  of  the  underlying  bit  string.  The  ||  symbol  indicates 

concatenation.  The  attribute  attrcom  represents  the  identity  tuple  {IDdomain,  idr+i  =  attr, 

e 

id^+2  =  'H(x)).  Let  =  (idi,...,id^))  =  (2  \6jQ\j)  +  Ui.  Now  we  can  define  the 

;=i 

ciphertext  CT  =  {CT ^om,  CT,  CTtag)  as  follows: 


CT: 


r,  Cid  =  sfiidPuC^  =  ®  (m  II  .r) 


Vv  6  V  :  C,  =  qM/3oPi 
yxeX,'ideT,:C^,  =  qM/3dPi 
Vw  G  W  :  Ch,  =  (k'  • 

Vy  G  Y  :  Cyjj  =  (attrcom),  Cy^i  =  a^3,(0)'Ki (attrcom),  Cy^i3  =  -T^y(0)'Ki (attrcom) 

Cy,2,i  =  qy(0)Pi,  CyX2  =  aqy(0)Pi  -Tqy(0)Pi 

( 


Vy  = 


attr 


if  attr  i  Ap 


^pinde x(a\.{r)  if  attr  g  Ap 

Vattr  G  Ap  :  Vpindexm^)  =  AttributeEncrypt(GP,  APa,  M  =  pindex{3.\Vc),  P  =  attr)) 


CTcom  =  CTtag  =  MACi:(Cr)  whcrc  k  =  h(v:) 


Decrypt(GP,  CT,  USK)  Mor  ±  The  decryption  process  again  follows  a  very  sim¬ 
ilar  path  as  the  decryption  process  for  CP-ASBE.  First,  the  policy  satisfaction  algorithm 
^(A)  is  run  to  determine  if  the  policy  associated  with  the  ciphertext  is  satisfied  by  the 
key  structure  provided  in  the  user  key.  If  the  algorithm  succeeds,  it  returns  a  set  of  labels 
on  the  root  node  that  can  be  used  to  satisfy  the  policy.  Otherwise  the  algorithm  returns 
the  empty  set  and  the  ciphertext  cannot  be  decrypted.  If  the  policy  satisfaction  algorithm 
succeeds,  the  decryption  algorithm  picks  one  of  the  labels  i  from  the  set  returned  by  ^(A) 
and  calls  a  recursive  function  DecryptNode(Cr,  US  K,t,  i)  on  the  root  node  of  the  tree. 
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If  ?  6  Y  (i.e.,  t  is  a  local  leaf  node),  then  DecryptNode  is  defined  as  follows.  If 
pindex(attr)  and  i  Aj  where  Ai  e  Adomain,user  then  return  J..  If  att(t)  = 
pindex(a\\r),  then  the  attribute  is  protected  and  must  be  recovered.  This  is  done  by 
iteratively  attempting  to  deerypt  P pmdexiam  until  a  key  is  found  that  results  in  Al  = 
pindex(a\\r).  This  is  an  Oiripin)  operation  where  np  is  the  number  of  protected  attributes 
in  the  policy  and  m  is  the  number  of  keys  the  user  possesses.  Once  the  appropriate  key 
is  found,  it  is  used  for  the  remaining  deeryption  steps.  If  the  attribute  is  not  protected 
then  att(t)  =  attr  e  Ai  where  Aj  6  Adomain,user  and  the  decryption  key  is  the  associated 

Let  IDattr  =  <idi,...,id^,id^+i  =  attr).  Compute  the  deeryption  key  set  IK;, 

=  Delegate(t/5i^  =  APa,  IDattr,  id;f+2  =  CT^om,  {  +  2).  Using  the  ciphertext 

at  node  t  and  IKi  attr™„,«ier  node  deeryption  is  defined  as  follows: 

DecryptNode(Cr,  USK,  t,  i) 

_  ^(CtAA,  Ki  i)e(CtA,2’  Ki^2)£(CtA,3,  Ki  j,) 

£{Ctx\^K2A)e{C,x2,  K22)e(CtX3,  ^2,3) 

_  e((?XO)'Hi(attrcom),  W1P2  +  riV2)e(aqt(0)A{i(attr^orn),  riV^)e(-Tqt(0)A{i(attrcoin),  ^^2) 

e(qtiO)Pi,  aP2  +  Wi'7T2(attreom)  +  oi^2  +  ^1^2  +  r[0]HdiI2)user))eiaqtiO)Pur2V^)e(-TqtiO)Pur2F2) 

^  _ g(-Ki  (attrcon,).f g(-Ki(attreon.). g(-Hi  (attrcon,). e^i  (attrcon,),F2)-""<(°)''i _ 

~  e{Pi ,P2r‘’‘^°'>e(Pi ,'W2(attrcom))*‘“'"'l  e(Pi ,V2)'^'*“>''2e(r’l ,F2)*™''‘e(Pl e(Pi , ,F2)-’'*(°>''2 

1 

“  e(Pi,  P2r‘i'^^HPi , 


At  this  point,  the  similarity  to  the  original  CP-ASBE  system  becomes  more  apparent. 
The  first  term  in  the  denominator  will  eombine  with  the  decryption  of  other  nodes  within 
the  same  authority  subtree  in  the  aceess  policy.  As  long  as  all  thresholds  are  met,  the 
polynomial  interpolation  will  eventually  produce  the  term  f(Pi,  ^2)“^’"*^°^  where  w  is  the 
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global  leaf  node  that  sits  at  the  root  of  this  authority  subtree.  This  term  in  the  denomi¬ 
nator  will  clear  the  original  blinding  factor  imposed  during  encryption  on  k'  at  node  w. 
However,  the  last  two  terms  produced  in  the  denominator  by  the  DecryptNode  process 
introduce  new  blinding  factors.  These  terms  themselves  are  blinded  by  the  attribute  set 
values  Ti,  r[0]  as  well  as  the  polynomial  term  qt. 

In  order  to  enable  the  full  expressive  power  of  attribute  sets,  we  must  utilize  the  trans¬ 
lation  parameters  included  in  the  ciphertext  in  a  manner  similar  to  the  original  CP-ASBE 
system  [17].  When  t  ^  Y  but  it  is  still  a  local  node  (i.e.,  t  is  a  local  threshold  node),  then 
DecryptNode  runs  as  follows: 

1.  Compute  which  contains  a  subset  of  any  kt  (i.e.,  the  threshold  at  node  M)  child 
nodes  z  such  that  z  6  only  if  either:  label  i  =  (i'  ||  j)  e  S^,  or  label  (i'  ||  /)  6  for 
some  /  j  and  z  is  a  translating  node  with  depth{i)  G  T^.. 

2.  Foreachnodez  6  B^  such  that  label  i  =  (i'  ||  j)  g  callDecryptNode(Cr,  USK,  t,  i) 
and  store  the  output  in  F^. 

3.  For  each  node  z  6  B,  such  that  the  label  (i'  ||  /)  g  and  /  j  call  DecryptN- 
ode(Cr,  USK,  t,  (i'  ||  /))  and  store  the  output  in  F[.  If  j  =  0  then  n  =  rj/yo  = 
(recall  the  restriction  in  the  user  key  generation  that  r\  =  riyo)  and  depth(i'  ||  /)  =  d. 
Translate  to  F^  as  follows: 


F,  =  e(C^„KF2MJ')F',  =  eiqmfidPuC- 


■F2))F'  =  e(PuF2y^^^^Fn+r;^^j,)p, 


1 


If  j  0  then  translate  to  F^  as  follows: 
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F,  =  e(C  ,,KF2Mr  -  KF2yi\j)F'^  =  e(q,(0)/3,Pu 


1 


Note  that  the  above  translations  are  between  sets  whose  recursive  depth  differs  by 
at  most  one.  More  specifically,  the  translation  is  from  the  outer  set  of  to  the 
outer  set  of  Aj/yy  if  j  0  or  the  outer  set  of  Aj  if  j  =  0.  Deeper  translations  can  be 
made  in  a  similar  manner  as  demonstrated  above  provided  the  relevant  translation 
indices  exist  in  T^..  Recall  that  these  translation  indices  are  created  during  encryp¬ 
tion  and  therefore  are  part  of  the  access  policy.  Hence,  they  are  available  only  at  the 
discretion  of  the  encrypting  party. 

4.  Compute  Ft  using  polynomial  interpolation  in  the  exponent  as  follows: 

Ft  =  W  where  k  =  index(z),  5'  =  {index{z)  :  z  6 

zeB, 

and  the  Lagrange  coefficient  A,  5  (x)  =  O  ^ 

jeSJ*i  ‘  ^ 

1 

“  e{Pi ,  ,  F2)mMe{P, , 


The  computations  above  work  up  the  access  policy  until  the  node  t  is  a  domain 
threshold  node.  When  this  occurs,  the  algorithm  performs  all  the  steps  for  a  local 
threshold  node  with  following  additional  step: 

5.  Using  the  methodology  established  in  Step  3  above,  translate  from  the  set  Ai  to  the 
outer  set  of  ^authority,domain,user  usiug  the  translation  parameters  along  with  the 
translation  components  of  the  user  key  Kf^  \.  If  the  access  policy  is  satisfied  by 
^authority,domain,user,  it  will  then  bc  possiblc  to  usc  the  pairing  of  Cv  with  A/Zj  [0]  and 
A,y,[o]  to  perform  a  final  translation.  This  changes  the  blinding  factor  to  ag  which  is 
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shared  amongst  all  nodes.  Recall  the  parent  of  a  domain  threshold  node  is  a  global 
leaf  node  in  the  multi-domain  case,  or  itself  in  the  single  domain  case.  Let  w  6  W  be 
the  relevant  global  leaf  node.  Once  enough  domain  threshold  nodes  are  decrypted  to 
satisfy  the  threshold  of  w,  store  the  result  of  the  interpolation  (as  outlined  in  Step  4) 
of  the  decrypted  domain  threshold  node  values  in  F'^.  F„  is  calculated  as  follows: 


F„  =  C„F'„  =  {k’  •  e{PuF2T^y-^^^e{PuP2T‘‘-^^^F'„ 

(k'  ■  e(P I , 

{k' ■  e{PuF2T^y'^^^^ 

~  e{Px ,  F2Y^‘‘-^^^e{P, ,  F{id{IVu,er)r^‘i-^^^ 

At  this  point,  no  more  translation  is  required  and  nodes  can  continue  to  be  com¬ 
bined  using  interpolation  outlined  in  Step  4  to  satisfy  the  global  thresholds  outlined 
in  the  policy.  Once  enough  nodes  of  the  access  policy  are  interpolated  into  the  root 
node,  Fr  takes  the  following  form  (recall  that  =  1  and  qR  =  s): 

^  k'-eiPuF2r^^  ^  k' 

e{PuF2r^^e{PuHd{I2)user)r^^  e{Pundi.I^user)r^^ 


Now  k'  can  be  recovered  using  e(C,y,  Kj^)  and  Fr.  Using  k'  and  Co-,  recover  m  and  x. 
If  F{(x)  CT com  then  return  ±,  otherwise  calculate  k  =  h(.r).  If  MACyt(Cr)  CLtag 
then  return  ±.  Otherwise,  return  m.  The  equations  for  the  recovery  steps  are  listed 
below: 


-  s(Cid,  Kid)FR  - 


eiPunHidil^userW^^k') 

e{Pi,nd{I^user)r^^ 
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4.5  Security 

In  this  section,  we  discuss  the  security  aspects  of  MA-AHASBE.  We  begin  by 
discussing  the  security  model  in  terms  of  a  security  game.  We  then  discuss  the  intuition 
for  the  security  of  the  system  from  both  the  single  authority  and  multiple  authority 
perspectives.  Next,  we  discuss  the  complexity  assumptions  that  the  security  proof  requires. 
The  complexity  assumptions  are  static,  but  are  non-standard.  However,  they  are  not  novel 
to  MA-AHASBE  and  in  fact  are  the  same  assumptions  that  are  used  in  EW-AHIBE  [89]. 
We  conclude  by  providing  a  sketch  of  the  proof.  The  proof  follows  the  same  structure  as  the 
one  presented  for  EW-AHIBE  [89].  The  details  of  the  instantiations  required  modifications 
from  the  EW-AHIBE  proof  in  order  to  account  for  multiple  authorities  and  the  additional 
components  for  ciphertexts  and  keys  that  exist  in  MA-AHASBE  but  not  in  EW-AHIBE. 
The  full  proof  details  are  provided  in  Appendix  A. 

4.5.1  Security  Model. 

MA-AHASBE-CPA  Security  The  following  is  the  definition  of  both  anonymity 
and  semantic  security  in  terms  of  a  security  game  between  a  challenger  and  an  adversary. 
The  game  generalizes  the  original  CP-ASBE  game  to  include  multiple  authorities.  The 
game  definition  is  given  in  terms  of  a  central  authority  that  generates  the  global  parameters. 
The  functionality  of  this  central  authority  could  be  replaced  by  the  local  authorities  running 
a  secure,  multi-party  computation  (SMPC)  protocol.  There  are  n  local  authorities.  The 
game  reduces  to  the  CP-ASBE  game  in  the  case  where  n  =  1.  In  this  case,  the  local 
authority  may  also  act  as  the  central  authority.  The  game  definition  relies  on  the  concept 
of  structural  equivalence  for  policies.  Two  policies  are  said  to  be  structurally  equivalent 
if  they  share  the  same  tree  structure.  This  means  that  starting  at  the  root  node  of  each  tree, 
nodes  from  both  trees  have  the  same  type  (e.g.,  translation  node,  global  leaf  node,  local 
leaf  node),  the  same  number  of  children,  and  the  same  threshold  values.  Eor  example,  if 
two  policies  are  structurally  equivalent,  the  same  q  coefficients  as  described  in  the  Encrypt 
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algorithm  can  be  used  to  satisfy  both  policies.  Two  policies  that  are  structurally  equivalent 
do  not  need  to  use  the  same  attributes  as  leaf  nodes,  or  even  use  the  same  authorities  in  the 
policy.  With  this  definition  in  place,  the  security  game  is  defined  as  follows: 


1.  Setup:  The  setup  is  divided  between  a  central  authority  and  n  local  authorities. 

(a)  A  central  authority  runs  the  algorithm  GlobalSetup  and  gives  the  global 
parameters  GP  to  every  local  authority  Ak  6  {Ak}ke[i,n]  and  to  the  adversary. 

(b)  Every  local  authority  Aj,  6  {Ak}keu,n]  takes  the  global  parameters  GP  and  runs 
AuthoritySetup  to  generate  the  set  of  authority  parameters  {APk]ke[\,n\-  The  set 
{APk]ke[i,n\  is  given  to  the  adversary. 

2.  Phase  1:  The  adversary  makes  up  to  qi  queries  for  private  keys  corresponding  to 
user  keys  USKi  with  key  structures  A,,  or  domain  keys  DS  Ki  where  i  e  [1,  <?1]. 

3.  Challenge:  The  adversary  submits  two  message-policy  pairs  (Mq,  'P*q)  and  (Mi,^p. 
Both  challenge  access  policies  must  satisfy  two  conditions.  First,  both  policies  must 
be  structurally  equivalent.  Second,  none  of  the  private  keys  received  in  Phase  1 
corresponding  to  user  keys  USKi  or  domain  keys  DSKi  for  /  6  [l,^i]  may  satisfy 
either  challenge  access  policy.  The  challenger  chooses  a  random  hiib  ^  {0, 1}  and 
encrypts  Mb  under  The  resulting  ciphertext  CT*  is  created  without  explicitly 
including  the  policy  and  is  given  to  the  adversary. 

Note:  If  the  challenge  access  policy  only  contains  one  global  leaf  node,  then  none  of 
the  private  keys  issued  during  Phase  1  are  allowed  to  satisfy  the  challenge  policy.  If 
the  challenge  access  policy  contains  at  least  two  global  leaf  nodes  created  with  the 
authority  parameters  PPk^  and  PPk2  such  that  k\  4^  k2  and  ki,k2  6  [l,n],  then  this 
means  the  adversary  could  satisfy  all  global  leaf  nodes  in  the  challenge  policy  with 
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private  keys  from  Phase  1,  but  there  must  exist  at  least  one  global  threshold  that  is 
not  satisfied  due  to  insufficient  private  keys  issued  to  a  single  IDuser- 

4.  Phase  2:  Phase  1  is  repeated  with  the  same  restrictions  as  described  above  for  total 
of  q  queries  where  q>q\. 

5.  Guess:  The  adversary  outputs  a  guess  b'  of  b. 

6.  Advantage:  The  advantage  of  an  adversary  ^  in  this  game  is  defined  as  Advj^  = 
\Pr\b'  =  b]-  ||. 

4.5.2  Security  Intuition. 

The  security  for  the  MA-AHASBE  system  reflects  the  security  of  the  two  underlying 
systems.  The  leaf  nodes  in  the  access  policy  are  essentially  problem  instances  of  LW- 
AHIBE,  split  across  the  access  policy  using  an  information  theoretic  linear  secret  sharing 
scheme.  The  EW-AHIBE  system  is  proven  using  the  dual-system  encryption  technique 
using  static,  but  non-standard  assumptions.  The  EW-AHIBE  method  for  creating  semi¬ 
functional,  partially  semi-functional  and  nominally  functional  ciphertexts  and  keys  require 
no  modification  to  work  in  MA-AHASBE.  The  only  difference  between  the  two  is  the  form 
of  a  successful  decryption.  In  EW-AHIBE,  a  successful  decryption  reveals  the  original 
message.  In  MA-AHASBE,  a  successful  decryption  of  a  leaf  node  takes  the  form  described 
in  the  algorithm  DecryptNode.  Also,  the  anonymity  from  EW-AHIBE  is  used  to  protect 
selected  attributes  from  being  disclosed  in  the  access  policy.  Since  an  attribute  in  MA- 
AHASBE  is  an  identity  in  the  underlying  AHIBE,  the  security  of  this  feature  is  a  direct 
consequence  of  the  anonymity  of  the  underlying  AHIBE.  Once  enough  leaf  nodes  are 
decrypted,  translating  and  combining  them  to  satisfy  the  linear  secret  sharing  thresholds 
becomes  an  instance  of  CP-ASBE.  CP-ASBE  is  proven  in  the  random  oracle  and  generic 
group  models  [17].  However,  since  MA-AHASBE  builds  on  EW-AHIBE  and  uses  the  same 
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dual  system  encryption  proof  structure,  the  entire  system  can  be  proven  without  oracles 
(random  or  group). 

Before  describing  the  structure  of  the  dual  system  encryption  proof,  we  first  provide 
some  additional  intuition  behind  the  security  of  MA-AHASBE  for  both  the  single  authority 
and  multi- authority  scenarios. 

4.5.2. 1  Single  Authority. 

We  first  look  at  the  single  authority  case.  Notice  that  in  the  ciphertext,  the  random 
value  k'  is  xor’d  with  the  message.  Thus,  the  adversary  must  recover  k',  otherwise  the  con¬ 
tents  of  the  message  m  are  information  theoretically  secure.  The  value  k'  only  appears  in 
one  place,  which  is  the  single  global  leaf  Cv^.  In  particular  we  have: 

C„  =  k'  ■eiPuF2r^^-e{PuP2Ar^ 

If  we  make  the  following  definitions,  where  x,  y,  and  z  are  all  part  of  the  authority  pa¬ 
rameters  available  to  the  adversary  and  s  is  the  random  value  chosen  during  encryption: 


y  =  e(Pi,P2AT^ 
z  =  xy 

C„  =  k'-  (xY)  =  k'-z^ 

It  becomes  clear  that  to  recover  k',  the  adversary  must  be  able  compute  the  inverse  of 
the  term.  The  adversary  has  z  through  the  authority  parameters,  but  does  not  have  s  di¬ 
rectly.  However,  s  has  been  split  into  linear  secret  shares  according  to  the  challenge  access 
policy.  These  shares  of  s  are  found  in  the  leaf  nodes  of  the  ciphertext,  represented  by  the 
value  ^(0).  Based  on  the  security  properties  of  LW-AHIBE,  the  only  way  to  "recover"  q(0) 
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is  through  successful  decryption  with  the  appropriate  attribute  key.  In  LW-AHIBE,  a  suc¬ 
cessful  decryption  reveals  the  original  message.  In  MA-AHASBE,  two  random  blinding 
factors  have  been  added  to  the  key  which  are  unknown  to  the  adversary.  This  makes  a  suc¬ 
cessful  decryption  of  a  leaf  node  take  the  form  described  in  the  algorithm  DecryptNode. 
Note  that  this  "recovery"  of  ^(0)  actually  places  it  in  the  exponent  of  three  base  elements. 
In  particular  it  is  of  the  form: 

1 


At  this  point,  the  adversary  must  only  have  keys  that  do  not  satisfy  the  challenge  pol¬ 
icy.  This  may  occur  for  one  of  two  reasons.  Either  the  adversary  cannot  properly  decrypt 
a  leaf  node,  or  the  adversary  cannot  perform  all  necessary  translations.  In  the  case  where 
the  adversary  cannot  properly  decrypt  a  leaf  node,  we  are  done  since  there  is  no  way  to 
satisfy  the  linear  secret  sharing  thresholds.  Otherwise  we  are  in  the  case  where  the  inability 
to  satisfy  the  policy  occurs  purely  because  of  the  inability  to  translate  between  recursive 
depths.  At  this  point,  the  problem  closely  represents  an  embedded  instance  of  CP-ASBE. 
Note  that  here,  the  domain  threshold  represents  the  root  node  of  an  CP-ASBE  system. 

4.5.2. 2  Multiple  Authorities. 

We  now  examine  the  case  when  the  challenger  submits  an  challenge  policy  with  mul¬ 
tiple  authorities.  Unlike  the  single  authority  case,  the  adversary  is  allowed  to  possess  keys 
that  successfully  decrypt  entire  subtrees  rooted  at  global  leaf  nodes.  In  order  to  prevent  the 
adversary  from  trivially  satisfying  the  entire  policy,  the  restriction  is  that  these  decryption 
operations  must  be  done  such  that  any  global  threshold  node  cannot  be  satisfied  with  global 
leaf  nodes  that  have  been  decrypted  with  the  same  IDuser-  This  decrypted  global  leaf  node 
takes  the  following  form: 
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{k’  ■ 


Here  it  is  evident  why  the  decryption  of  global  leaf  nodes  must  have  been  decrypted  with 
the  same  IDuser-  The  attacker  at  this  point  has  the  additive  shares  of  s  in  the  terms  qw{0) 
given  above.  If  the  attacker  attempts  to  interpolate  the  decryption  of  leaf  nodes  with  differ¬ 
ent  (ID)user,  then  the  second  term  in  the  denominator  of  F„  will  not  properly  combine  the 
shares  of  s.  Furthermore,  the  attacker  does  not  have  anything  that  can  be  paired  that  will 
eliminate  this  blinding  factor.  The  only  potentially  useful  terms  available  are: 

Cid  =  sfiidPy 

Kid  =  ^^nHid{IF)user) 

KidM  =  '-^HdilDuser) 


The  Kid^o]  term  is  not  useful,  even  if  a  translation  parameter  exists  that  would  cancel  the  ySo 
term.  This  is  because  the  result  would  still  be  blinded  by  r[0]  which  is  not  available  to  the 
adversary.  The  remaining  two  terms  C,y  and  Kid  are  useful  for  clearing  the  IDuser  blinding 
factor  only  at  the  root  node,  in  other  words  after  enough  global  leaf  nodes  have  been  inter¬ 
polated  to  meet  the  global  root  node  threshold  value.  This  is  because  C,y  contains  an  s  term 
and  not  q{0)  terms.  Furthermore,  these  are  the  only  terms  available  that  contain  as  all 
the  other  terms  used  in  the  CP-ASBE  scheme  use  separate  (5  values. 

4.5.2.3  Key  Escrow. 

In  MA-AHASBE,  it  is  important  to  recognize  that  the  central  authority  does  not  have 
key  escrow  in  the  system.  This  is  because  the  central  authority  does  not  have  the  a  a  value 
which  is  kept  private  by  the  local  authorities.  The  central  authority  does  have  access  to 
the  value  ag  which  does  give  the  central  authority  the  ability  to  facilitate  a  degree  of  col¬ 
lusion.  In  order  to  support  collusion,  a  malicious  central  authority  must  find  two  or  more 
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users  from  different  domains  that  are  willing  to  collude.  These  users  can  decrypt  ciphertext 
nodes  until  they  reach  a  global  leaf  node.  At  this  point,  the  users  would  be  prevented  from 
combining  the  global  leaf  nodes  since  the  leaf  nodes  would  have  been  decrypted  with  dif¬ 
ferent  user  keys.  Critically  though,  at  this  point  the  local  authority  blinding  factor  has  been 
removed  and  the  only  blinding  factor  remaining  is  tied  to  user  identifiers.  Recall  a  global 
leaf  node  at  this  point  is  in  the  following  form: 

(k'  ■ 


The  central  authority,  with  knowledge  of  ag,  can  eliminate  the  blinding  factor  e(Pi ,  Fiid{I 
since  the  ciphertext  contains  q„{0)Pi  for  each  domain  threshold  node.  The  central  author¬ 
ity  can  use  these  values  to  compute  the  value  for  each  global  leaf  node  through 

interpolation.  It  can  now  eliminate  the  blinding  factor  by  pairing  with  Fiidil Duser)  and 
multiplying  the  result  with  F„.  The  result  can  now  be  interpolated  up  to  the  root  node  and 
the  message  can  be  recovered. 

The  ability  to  support  this  type  of  collusion  is  why  the  central  authority  is  required  to 
be  trusted.  One  way  to  work  around  this  is  to  decentralize  the  central  authority  as  described 
previously  in  §4.3.2. 1. 

4.5.3  Complexity  Assumptions. 

We  now  review  the  complexity  assumptions  used  in  the  MA-AHASBE  security  proof. 
Note  that  these  assumptions  are  for  Type-3  pairings  and  are  based  on  earlier  work  by  done 
in  [89].  Here,  Q  =  {p,  Gi,  G2,  Gj-,  e,  Fi,F2)  represents  an  asymmetric  pairing  and  is  a 
probabilistic,  polynomial  time  algorithm  (PPTA)  that  outputs  0  or  1. 


Assumption  LWl:  Define  a  distribution  D  as  follows:  Fi 


[,  a,  b,  s 


D  =  {Q,  Fi ,  bsFi ,  sFi ,  aFi ,  ab^Fi ,  bFi ,  b^Fi ,  asFi ,  b^sFi ,b^Fi,  b^ sFi ,  F2,  bF2) 


72 


The  LWl  problem  is  to  decide,  given  (D,Zi),  if  Zy  =  ab^sFy  or  Zy  £u  Gi.  The 
advantage  of  an  algorithm  Jl  in  solving  the  LW 1  problem  is  given  by: 


Adv;^”'^  =  \Pr[Jl(D,ab^sFy)  =  1]  -  Pr[Ji{D,  TO  =  1]| 


The  (6,  t)-LW  1  assumption  holds  in  Q  if  for  any  adversary  running  in  time  at  most  t, 
<  e. 

Assumption  LW2:  Define  a  distribution  D  as  follows:  Fi  F2  ^  G^,  d,  b,  c, 

X  <—  hp,  Y2  <—  G2; 


dd  =  (Q,Fy,dFy,d^Fy,bxFy,dbxFy,d^xFy,F2,dF2,dF2,bF2,bF2,cF2) 


The  LW2  problem  is  to  decide,  given  (D,  Z2),  if  Z2  =  bcF2  or  Z2  eu  ^2-  The  advantage 
of  an  algorithm  Jl  in  solving  the  LW2  problem  is  given  by: 

Adv;^'^^  =  \Pr[Jl{D,bcF2)  =  1]  -  Pr[m{D,  Y2)  =  1]| 


The  (6,  t)-LW2  assumption  holds  in  Q  if  for  any  adversary  Jl  running  in  time  at  most  t. 


Adv^'"^  <  6. 


Decisional  Bilinear  Difiie-Hellman  in  Type-3  pairings  (DBDH-3)):  Define  a  distribution 


D  as  follows:  F 


1  G^;  F2 


x,y,z<^  1:p  and  Yj 


dd  =  {Q,Fy,xFy,yFy,zFy,F2,xF2,yF2) 


The  DBDH-3  problem  is  to  decide,  given  (D,Zt),  if  Zj  =  e(Fy,F2)^^  or  Zt  &u 
The  advantage  of  an  algorithm  ^  in  solving  the  DBDH-3  problem  is  given  by: 

Adv;^^"^-^  =  \Pr[Jl(D,e(Fy,F2y^^)  =  1]  -  Pr[Jl(D,YT)  =  1]| 

The  (e,  t)-DBDH-3  assumption  holds  in  ^  if  for  any  adversary  running  in  time  at 
most  t,  <  e. 
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Assumption  Al:  Define  a  distribution  D  as  follows:  Fi  ^  F2  ^  a,  z,  d,  s, 
X  ^  Zp  and  Yi  ^  Gi; 

2)  =  {Q,Fi,zFi,dzFi,azFi,adzFi,szFi,F2,zF2,aF2,xF2,{dz- ax)F2) 

The  Al  problem  is  to  decide,  given  (£),Zi),  if  Zi  =  sdzFi  or  Zi  6j/  Gi.  The  advantage 
of  an  algorithm  FI  in  solving  the  Al  problem  is  given  by: 

Adv^i  =  \Pr[F{{T),  sdzFd)  =  1]  -  Pr[F{{D,  Tj)  =  1]| 

The  (6,  0-Al  assumption  holds  in  Q  if  for  any  adversary  FI  running  in  time  at  most  t, 
Ad\^  <  6. 

4.5.4  Security  Theorem. 

We  can  now  state  the  security  theorem: 

Theorem  4.1.  Given  q  is  the  number  of  adversary  queries,  if  the  (e,  t')-LWl,  (e,  t')-LW2, 
(e,  f  )-DBDH-3  and  (e,  t')-Al  assumptions  hold,  then  MA-AHASBE  is  (e,  t,  q)-ANO-IND- 
ID-CCA  secure  where: 


e  <  Clwi  +  2q€LW2  +  ^dbdh-3  +  ^ai 

4.5.5  Proof  Overview. 

The  proof  of  Theorem  4.1  follows  the  same  dual  system  encryption  strategy  as  [89], 
with  the  adjustments  necessary  to  simulate  the  unique  aspects  of  MA-AHASBE.  In  this 
section  we  present  the  structural  elements  of  the  proof.  The  actual  instantiations  from  the 
problem  instances  for  each  portion  of  the  proof  are  presented  in  Appendix  A.  Intermediate 
steps  to  show  that  the  components  are  well-formed  are  not  presented  in  Appendix  A,  but 
since  the  terms  follow  the  same  structure  as  [89]  the  same  intermediate  steps  presented 
there  can  be  used  for  MA-AHASBE.  The  security  for  both  EW-AHIBE  and  MA-AHASBE 
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depends  on  the  following  complexity  assumptions:  LWl,  LW2,  DBDH-3,  and  Al.  In 
summary,  the  complexity  assumptions  play  the  following  roles  in  the  security  reductions: 

•  LWl:  The  ability  of  the  adversary  to  distinguish  between  a  normal  ciphertext  and  a 
semi-functional  ciphertext  is  reduced  to  solving  LWl. 

•  LW2:  The  ability  of  the  adversary  to  distinguish  between  a  normal  key  and  a  semi¬ 
functional  key  on  the  k’th  key  query  is  reduced  to  solving  LW2. 

•  DBDH-3:  The  ability  of  the  adversary  to  distinguish  between  a  semi-functional 
encryption  of  the  real  message  from  a  semi-functional  encryption  of  a  random 
element  of  Gr  is  reduced  to  solving  DBDH-3. 

•  Al:  The  ability  of  the  adversary  to  distinguish  between  a  random  message  encrypted 
under  a  random,  structurally  equivalent  policy  and  a  chosen  message  encrypted  under 
a  chosen  policy  is  reduced  to  solving  Al. 

The  proof  uses  a  simulator  that  works  in  a  manner  very  similar  to  the  simulator  used  in  LW- 
AHIBE.  The  key  difference  is  that  the  simulator  for  MA-AHASBE  has  to  simulate  a  set  of 
global  parameters,  authority  parameters  for  multiple  authorities,  a  more  complex  ciphertext 
relative  to  EW-AHIBE,  as  well  as  some  additional  key  elements.  This  simulator  takes  as 
input  LWl,  LW2,  DBDH-3  and  Al  with  either  real  components  or  random  components. 
The  same  hybrid  sequence  of  2^  -l-  4  games  defined  in  [89]  are  used  here: 

•  Gamereai-  The  real  security  game  defined  in  Section  4.5.1. 

•  Gameo'.  The  challenge  ciphertext  is  semi-functional  and  all  keys  returned  are  normal. 

•  Gamekfl  for  I  <  k  <  q:  The  k’th  key  is  partial  semi-functional,  the  first  k  -  I  keys  are 
semi-functional  and  the  rest  of  the  keys  are  normal. 

•  Gamekj  for  I  <  k  <  q:  The  k’th  key  is  fully  semi-functional. 
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•  Game M-random-  All  keys  returned  are  semi-functional  and  the  challenge  ciphertext 
encrypts  a  random  message. 

•  Game  final'-  All  keys  returned  are  semi-functional  and  the  challenge  ciphertext 
encrypts  a  random  message  to  a  random,  structurally  equivalent  policy. 

The  games  are  ordered  as  Game  real,  Gameo,  Game  i  a.  Game  i  a,  ...,  Gameqft,  Gameqj, 

Game  jyi-random.  Game  final-  Let  Xreal,  Xq,  Oj  Aj  j,  ...,  XqQ,  Xq\,  Xj^f-random,  Xfinal  bC  the  CVCnt 

that  Jl  wins  in  Gamereai,  Gameo,  Gameio,  Gameii,  ...,  Gameqo,  Gameqi,  Game  M-random, 
Game  final  respectively.  Gameof  is  the  same  as  Gameo- 

It  is  important  to  recognize  that  the  main  components  in  MA-AHASBE  are  nearly 
direct  instances  of  LW-AHIBE.  Eor  user  keys,  the  key  difference  is  that  the  function 
RestrictToUser  appends  two  additional  components  onto  the  K2f  portion  of  the  key. 
During  leaf  node  decryption,  these  additive  terms  become  multiplicative  terms  in  the 
decrypted  result.  In  the  ciphertext,  there  are  q  terms  that  represent  the  secret  split  over 
a  policy.  It  is  a  straightforward  exercise  to  show  that  these  additional  terms  do  not  interfere 
with  the  interaction  between  normal  and  semi-functional  ciphertexts  with  normal,  semi¬ 
functional,  partially  semi-functional,  and  nominally  functional  keys.  Therefore,  MA- 
AHASBE  can  directly  leverage  the  constructions  as  described  in  [89]  for  creating  semi- 
functional  components  without  modification.  MA-AHASBE  semi-functional  ciphertext 
components  are  embedded  in  the  local  leaf  nodes.  MA-AHASBE  domain  keys  map  directly 
to  LW-AHIBE  keys  so  creating  semi-functional  domain  keys  is  exactly  the  same  as  LW- 
AHIBE.  A  semi-functional  user  key  is  one  that  is  generated  from  a  semi-functional  domain 
key.  The  same  logic  applies  to  all  types  of  semi-functionality  (partial,  nominal,  normal).  It 
is  straightforward  to  verify  that  MA-AHASBE  semi-functional  keys  and  ciphertexts  behave 
as  expected  for  a  dual  system  encryption  proof. 


76 


In  Game  final,  a  random  message  is  encrypted  to  random  policy,  so  we  know  that 
Pr\X final]  =  ^-  In  order  to  support  the  inequality  in  Theorem  1,  we  prove  that  the  same 
five  lemmas  presented  in  [89]  hold  for  MA-AHASBE.  These  lemmas  are: 

•  Lemma  4.1:  \Pr[Xreai]  -  <  ^lw\ 

•  Lemma  4.2:  |Er[A;t-i,i]  -  Pr\Xkfl\\  <  ^lwi  iox\  <k  <q 

•  Lemma  4.3:  \Pr{Xkfl\  -  Pr{Xkf]\  <  etwi  for  I  <k  <  q 

•  Lemma  4.4:  \Pr\Xq  i\  -  Pr\XM-random\\  ^  ^dbdh-3 

•  Lemma  4.5.  \P^'[Xj^^_|.andom\  Pf\j^final\\  —  ^Al 

The  actual  instantiations  for  each  lemma  are  presented  in  Appendix  A. 

4.5.6  Chosen  Ciphertext  Security  Security. 

The  construction  for  MA-AHASBE  uses  the  generic  chosen  ciphertext  security  (CCA) 
transform  described  in  [19].  Often  systems  are  demonstrated  only  with  CPA  security,  given 
the  existence  of  such  generic  transforms.  In  the  case  of  MA-AHASBE,  care  must  be  taken 
to  ensure  that  the  transform  is  properly  applied.  In  particular,  this  is  due  to  the  requirement 
that  the  CCA  transformation  requires  that  the  encrypting  party  be  able  to  generate  the 
private  key  for  an  arbitrary  identity.  In  other  words,  it  must  act  as  a  private  key  generator 
for  an  identity  whose  value  is  the  commitment  message.  This  functionality  is  provided  by 
the  EW-AHIBE  system  by  allowing  users  to  delegate  to  arbitrary  identities,  assuming  there 
are  enough  levels  of  delegation  authority  present  in  that  user’s  private  key.  The  ability  to 
finely  control  this  amount  of  delegation  authority  is  necessary  for  MA-AHASBE.  If  a  user 
is  allowed  to  delegate  arbitrarily,  they  could  then  become  unauthorized  subdomains. 

The  key  aspect  of  the  security  of  MA-AHASBE  with  regards  to  the  issues  described 
above  is  that  the  user  key  is  both  required  to  delegate  one  level  in  order  to  decrypt  and  that 
the  user  key  is  authorized  to  delegate  exactly  one  level.  If  the  user  were  to  try  to  misuse 
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their  one  level  of  delegation  to  forge  a  key  for  an  unauthorized  subdomain,  the  resulting 
key  would  not  be  able  to  ereate  further  delegations.  Sinee  at  least  one  level  of  delegation  is 
required  to  deerypt,  this  new  key  would  be  useless.  Sinee  this  tight  eontrol  over  delegation 
authority  is  a  striet  requirement,  the  MA-AHASBE  eonstruetion  is  deseribed  with  the 
transform  applied.  The  proof  of  seeurity  given  above  demonstrates  that  MA-AHASBE 
is  CPA  seeure.  It  is  a  straight  forward  exereise  to  verify  that  the  additional  eomponents 
involved  in  the  eonstruetion  are  a  direet  applieation  of  CCA  transform  deseribed  in  [19]. 

4.6  Conclusions  and  Future  Work 

The  MA-AHASBE  system  fills  a  gap  in  CP-ABE  systems,  speeifieally  through  its 
eombination  of  large  universe,  multi- authority,  delegation  and  attribute-set  eapabilities. 
Euture  work  involves  analyzing  its  performanee,  espeeially  in  the  deeentralized  ease.  Also, 
it  may  be  possible  to  use  the  same  teehniques  with  another  AHIBE  [90]  to  build  a  system 
with  stronger  seeurity  features.  It  would  also  be  useful  in  an  enterprise  environment  to  sign 
messages  with  attributes,  either  eompound  or  singleton,  in  order  to  verify  the  authentieity 
of  messages.  In  MA-AHASBE,  a  eiphertext  ean  be  ereated  by  anyone,  so  a  signing 
meehanism  would  allow  users  to  verify  that  messages  have  been  viewed/approved  by  other 
users  with  eertain  attributes.  A  straight  forward  approaeh  might  be  taken  based  on  the 
suggestions  found  in  [47]  for  the  singleton  ease. 
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V.  MA-AHASBE  Based  Access  Control  in  a  Cloud  Supported  Publish- Subscribe 

Data  Model 


This  chapter  presents  an  approach  for  securing  data  with  public  cloud  service 
providers  (CSPs).  It  defines  two  models  of  security  which  emphasize  that  CSPs  may 
be  trusted  with  availability  operations,  but  not  with  confidentiality.  One  model  called 
A-trusted  provides  no  further  trust  beyond  availability  operations,  while  a  more  relaxed 
variant  called  ACE-trusted  allows  computation  (i.e.,  system  integrity)  and  certain  access 
control  decisions.  The  A-trusted  model  may  be  appropriate  for  peer-to-peer  type  networks, 
while  the  ACE-trusted  model  may  be  more  appropriate  for  CSPs.  In  order  to  build 
applications  with  these  security  models,  a  framework  called  Axon  is  introduced.  Axon 
bridges  applications  and  CSPs  by  providing  a  small  set  of  highly  available  data  structures: 
maps,  queues,  and  topics.  Security  can  then  be  layered  on  these  data  structures  to  create 
ACE- trusted  data  structures  and  protocols.  A  microblogging  application  called  Critter  is 
built  using  this  layered  approach.  Experimental  results  show  that,  while  there  is  certainly 
cost  associated  with  encryption,  decryption  and  increased  payload  sizes,  the  security 
tradeoff  may  be  worth  it  for  situations  where  preventing  disclosure  of  sensitive  data  is 
critical. 

5.1  Introduction 

Cloud  computing  is  becoming  an  important  method  for  storing  and  processing  data. 
One  of  the  primary  draws  of  public  cloud  computing  is  that  cloud  service  providers  (CSPs) 
can  leverage  economy  of  scale  to  provide  cost-effective  services.  However,  outsourcing 
data  to  a  third  party  brings  with  it  important  security  concerns.  This  chapter  explores  an 
approach  that  helps  to  address  these  concerns. 
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To  address  the  issue  of  security,  we  propose  a  security  model  based  on  the 
information  security  principle  of  availability.  While  the  information  security  principles 
of  confidentiality  and  integrity  can  typically  be  enforced  using  cryptographic  techniques, 
the  requirement  to  trust  CSPs  with  availability  of  data  is  difficult  to  avoid  without  forcing 
clients  to  maintain  an  entire  replica  of  all  data  provided  to  the  CSP.  In  many  cases, 
this  approach  defeats  the  purpose  of  using  cloud  services.  Fortunately,  the  business 
model  for  CSPs  usually  depends  on  providing  high  availability  of  data.  With  CSPs 
capable  of  providing  high  availability  service  level  agreements  (SLAs)  to  their  clients, 
the  security  concern  shifts  from  availability  to  confidentiality  and  integrity.  Our  proposed 
security  model,  called  Availability-trusted  (or  A-trusted),  only  trusts  the  CSPs  with  making 
sure  data  CSPs  receive  are  made  available  to  clients  according  to  any  applicable  SLAs. 
A  specialization  of  this  security  model  called  Availability -Computability -Enforce  ability - 
trusted  (or  ACE-Trusted)  adds  additional  trust  with  computation  and  the  enforcement  of 
availability  access  controls  (not  confidentiality  access  control).  The  A-trusted  model  is 
appropriate  for  situations  where  there  is  a  minimal  amount  of  trust,  such  as  in  peer-to-peer 
networks.  The  ACE-trusted  model  is  appropriate  for  situations  such  as  a  CSP,  where  some 
additional  trust  is  warranted  in  order  to  avoid  the  extra  computational  cost  associated  with 
the  A-trusted  model. 

We  believe  that  by  adopting  such  conservative  security  models,  clients  may  be  more 
willing  to  build  cloud  computing  applications  that  must  process  sensitive  data  that  clients 
may  otherwise  be  unwilling  to  outsource  to  a  CSP.  In  order  to  investigate  how  applications 
could  be  built  under  these  models,  we  have  developed  a  simple  messaging  application  we 
call  Critter.  Critter  supports  the  basic  messaging  capabilities  of  popular  microblogging 
applications  such  as  Twitter  and  Instagram.  It  allows  users  to  post  messages  to  their  public 
feed,  where  any  followers  of  that  feed  will  receive  them.  Users  may  tag  messages  by 
including  the  hashtag  symbol  #  followed  by  a  keyword  of  the  user’s  choice.  Users  may 
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then  follow  these  tags  for  topics  which  interest  them.  Users  may  also  direct  messages  to 
only  be  sent  to  specific  users  rather  than  their  public  feed  by  including  the  target  users’ 
handle  preceded  by  the  @  symbol.  In  Critter,  all  messages  are  protected  from  disclosure 
to  the  CSP  through  encryption.  We  believe  that  Critter  represents  an  application  that  has 
sufficient  complexity  to  be  useful  for  understanding  the  challenges  of  these  models,  while 
being  simple  enough  to  study  and  understand  how  the  underlying  security  components 
work. 

Finally,  in  building  Critter  we  realized  that  we  needed  a  framework  to  help  bridge  the 
gap  between  the  requirements  of  the  security  model  and  the  services  provided  by  a  CSP. 
We  describe  Axon,  which  is  the  resulting  framework  that  we  developed.  The  core  concept 
of  Axon  is  that  the  interface  between  client  applications  and  cloud  infrastructure  should  be 
a  small  set  of  easily  understood  data  structures.  Currently,  Axon  supports  three  core  data 
structures:  maps  (also  called  dictionaries  or  key-value  stores),  queues,  and  topics.  Axon 
also  supports  a  distributed  event  system  that  informs  connected  clients  when  changes  to 
these  data  structures  occur.  By  focusing  on  a  small  set  of  data  structures,  the  cloud  side 
of  Axon  can  ensure  that  the  data  placed  in  these  data  structures  is  highly  available  and 
persistent.  On  the  client  side,  the  core  data  structures  serve  as  building  blocks  for  more 
complex  structures  that  provide  confidentiality  and  integrity  guarantees  that  support  the 
security  model.  Applications  such  as  Critter  can  then  use  these  secure  data  structures. 
This  layered  approach  to  security  provides  a  way  to  manage  the  complexity  that  arises  for 
applications  that  require  both  security  and  high  availability. 

This  chapter  is  divided  into  six  sections.  The  next  section  discusses  background  and 
related  work.  We  then  discuss  our  proposed  security  and  dependability  models  in  Section 
3.  In  Section  4,  we  describe  the  Axon  framework.  We  describe  how  we  use  Axon  to  build 
the  Critter  application  in  Section  5  and  present  experimental  results.  We  conclude  the  paper 
in  Section  6  along  with  thoughts  on  future  work. 
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5.2  Background  and  Related  Work 
5.2.1  Definitions. 

Attribute-Based  Access  Control  An  access  control  method  where  subject  requests  to 
perform  operations  on  objects  are  granted  or  denied  based  on  assigned  attributes 
of  the  subject,  assigned  attributes  of  the  object,  environment  conditions,  and  a  set  of 
policies  that  are  specified  in  terms  of  those  attributes  and  conditions  (NIST  definition 
[58]). 

Key-Pair  Public  Key  Encryption  (KP-PKE)  This  type  of  public  key  cryptography  refers 
to  asymmetric  (public/private)  key  pairs  that  are  tightly  coupled  in  that  one  cannot 
be  changed  independent  from  the  other  (e.g.,  RSA,  ElGamal).  This  term  is  used 
to  distinguish  it  from  other  types  of  public  key  cryptography  such  as  identity- 
based  encryption  [95]  (or  attribute-based  encryption  [13,  94])  where  the  public  keys 
are  fixed  strings  and  the  private  keys  are  updated  independently  by  a  private  key 
generator. 

Ciphertext-Policy  Attribute-Based  Encryption  (CP-ABE)  This  term  refers  to  a  family 
of  cryptographic  systems  [13,  31,  32,  52]  where  users  are  given  cryptographic  keys 
that  represent  attributes.  In  many  CP-ABE  systems,  the  attributes  are  fixed  strings 
(e.g.,  “User”,  “Active”,  “Student”).  The  cryptographic  keys  corresponding  to  these 
fixed  string  attributes  are  provided  by  a  trusted  private  key  generator.  Ciphertext  is 
created  by  combining  an  access  policy  over  a  set  of  attributes,  a  message,  and  a  set 
of  public  parameters  provided  by  the  private  key  generator. 

Authenticated  Encryption  with  Associated  Data  (AEAD)  This  is  a  type  of  symmetric 
key  encryption  which  provides  confidentiality,  integrity,  and  authenticity  for  the 
encrypted  data.  The  AEAD  encryption  takes  as  input  a  plaintext  that  requires 
confidentiality  protection,  plaintext  that  will  not  be  encrypted  but  must  not  be  altered 


82 


(i.e.,  the  associated  data),  and  the  encryption  key.  As  a  result,  the  AEAD  encryption 
algorithm  produces  ciphertext  and  an  authentication  tag.  AEAD  decryption  takes 
as  input  the  ciphertext,  the  plaintext  associated  data,  authentication  tag,  and  the 
encryption  key.  The  decryption  algorithm  only  succeeds  if  the  data  (both  the 
ciphertext  and  the  associated  data)  have  not  been  altered  in  any  way.  If  decryption 
succeeds  it  produces  the  original  plaintext.  If  the  data  has  been  altered,  the  decryption 
will  detect  this  condition  and  fail.  Eor  this  paper,  we  assume  that  the  AEAD 
algorithm  is  random  in  that  each  invocation  of  the  algorithm  produces  different 
results  even  if  the  same  inputs  are  used. 

Message  Authentication  Code  (MAC)  A  message  authentication  code  is  a  cryptographic 
primitive  that  provides  both  integrity  and  authentication  guarantees  for  messages.  A 
MAC  generation  algorithm  takes  as  input  a  message  and  a  cryptographic  key  and 
produces  a  tag.  A  corresponding  verification  algorithm  takes  as  input  a  message, 
a  cryptographic  key  and  a  tag  produced  by  the  generation  algorithm.  If  the  tag 
was  created  by  the  same  message  and  cryptographic  key  as  the  one  provided  to 
the  verification  algorithm,  the  verification  succeeds  and  fails  otherwise.  Eike  a 
cryptographic  hash  function,  a  MAC  ensures  that  a  message  has  not  been  altered, 
thereby  providing  integrity.  However,  unlike  a  cryptographic  hash  function,  the 
MAC  algorithms  require  a  secret  key.  This  provides  an  authentication  mechanism 
since  only  someone  in  possession  of  the  secret  key  can  create  tags  that  verify  with 
that  particular  key. 

WebSockets  /  Long  Polling  WebSockets  is  a  protocol  that  provides  full-duplex  communi¬ 
cation  over  the  Hypertext  Transfer  Protocol  (HTTP).  It  is  primarily  designed  to  facil¬ 
itate  real-time  applications  that  run  in  Internet  browsers,  but  can  be  used  in  anywhere 
where  full-duplex  communication  is  desired.  However,  WebSocket  connections  may 
fail  when  behind  certain  types  of  proxies  which  do  not  support  them.  Eong  polling 
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is  an  alternative  technique  that  also  provides  full-duplex  communication  over  HTTP. 
Long  polling  will  generally  work  through  proxies  and  firewalls,  but  has  increased 
latency  and  overhead  costs  when  compared  to  a  protocol  such  as  WebSockets.  In 
long  polling,  a  client  sends  a  normal  HTTP  request  for  data.  If  the  server  has  data 
to  send,  it  will  send  it  immediately  and  close  the  HTTP  connection.  When  the  client 
receives  the  data,  it  immediately  issues  another  request.  When  the  server  does  not 
have  data  to  send  the  client,  it  keeps  its  side  of  the  HTTP  connection  open  until  it 
either  has  data  to  send  or  a  timeout  occurs.  The  worst  case  latency  occurs  when  the 
server  determines  it  has  data  to  send  the  client  immediately  after  it  has  closed  the 
previous  HTTP  connection  (either  due  to  a  previous  message  or  a  timeout  occuring). 
In  this  case,  the  server  must  wait  for  the  client  to  issue  its  next  connection  request  in 
order  to  send  the  data. 

5.2.2  Related  Work. 

Access  control  and  confidentiality  in  publish/subscribe  (pub-sub)  networks  has  been 
an  active  research  area  for  many  years.  Pub-sub  systems  can  be  described  as  either  topic 
based  or  content  based.  In  topic  based  pub-sub,  users  subscribe  to  topics  by  keyword.  Any 
messages  published  to  that  topic  will  be  received  by  users  who  are  subscribed.  Content 
based  pub-sub  is  an  enhancement  where  users  submit  filters  that  describe  the  type  of  content 
that  they  wish  to  recieve.  When  a  message  is  published  to  the  system,  if  the  content  of  a 
message  matches  the  filter  provider  it  is  routed  to  the  user. 

While  work  has  been  done  in  protecting  confidentiality  and  integrity  for  both  content 
based  pub-sub  ([8,  12,  59,  60,  77,  86])  and  topic  based  systems,  this  work  focuses  on  a 
topic  based  systems.  Due  to  the  recent  popularity  of  social  networks  such  as  Twitter  and 
Instagram  using  this  type  of  messaging  system,  this  type  of  messaging  is  also  referred  to  as 
microblogging.  One  of  the  first  examples  of  protecting  confidentiality  in  a  microblogging 
application  is  #h00t  [6].  The  goal  of  #h00t  is  to  protect  messages  from  being  intercepted 


84 


and  censored  by  the  service  provider  or  some  other  controlling  entity  such  as  a  government. 
The  system  relies  on  shared  group  keys  that  are  distributed  in  an  ad-hoc  fashion  amongst 
group  members.  Another  system  Hummingbird  [33]  also  protects  the  content  of  tweets  by 
encrypting  them  first.  Hummingbird  uses  efficient  cryptographic  primitives,  but  requires 
that  followers  request  approval  from  publishers  to  follow  certain  topics.  In  [87],  the  authors 
propose  a  technique  called  k-subscription  to  protect  the  service  provider  from  discovering 
which  channels  in  which  users  have  an  interest.  Users  subscribe  to  additional  noise 
channels  in  order  to  mask  their  true  channels  of  interest.  The  technique  is  not  designed 
to  protect  the  confidentiality  of  the  content  of  the  tweets,  instead  relying  on  a  system  such 
as  #h00t  or  Hummingbird  for  that  functionality. 

5.2.3  MA-AHASBE. 

MA-AHASBE  (Multi-Authority  Anonymous  Hierarchical  Attribute-Set  Based  En¬ 
cryption)  is  a  ciphertext-policy  attribute-based  encryption  (CP- ABE)  [13]  system  with  a 
rich  set  of  capabilities.  Here  we  provide  a  brief  summary  of  its  features.  Eull  details  of  the 
system  including  security  proofs  can  be  found  in  its  full  technical  report  [99] . 

MA-AHASBE  was  developed  to  help  facilitate  the  use  of  CP-ABE  within  an 
federated,  enterprise  system.  In  this  type  of  system,  there  may  be  multiple  distinct 
organizations  that  wish  to  work  together  and  share  a  common  attribute  infrastructure. 
In  MA-AHASBE,  each  of  these  organizations  is  called  an  authority.  If  these  authorities 
cooperate  and  agree  on  a  common  set  of  global  parameters,  including  a  list  of  user 
identifiers,  it  is  possible  for  users  to  receive  attribute  keys  from  each  authority  and  use 
them  to  satisfy  policies.  This  is  useful  in  situations  where  a  single  user  must  possess 
attributes  from  multiple  organizations.  Eor  example,  say  a  student  at  a  university  is  doing 
an  research  internship  for  a  corporation.  There  may  be  documents  that  should  only  be 
accessible  to  students  from  the  university  who  are  participating  in  the  internship.  Under  a 
multi-authority  system  such  as  MA-AHASBE,  the  student  can  receive  a  “Student”  attribute 
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from  the  university  and  a  “Intern”  attribute  from  the  corporation.  The  student  could  then 
satisfy  an  access  policy  that  requires  both  attributes.  The  two  authorities  do  not  need  to 
share  any  secret  key  material  in  order  to  do  this,  they  must  only  agree  on  the  user  identifier 
to  use  (which  is  part  of  the  public,  global  parameters)  when  generating  the  attributes. 

MA-AHASBE  also  allows  authorities  to  delegate  responsible  to  lower  level  domains. 
In  MA-AHASBE,  these  lower  level  domains  have  full  autonomy  to  create  keys  for  any 
attributes  they  need.  The  keys  they  generate,  however,  are  bound  to  that  specific  domain. 
Eor  example,  the  university  in  the  previous  example  may  wish  to  delegate  some  if  its 
authority  to  the  college  of  engineering.  We  distinguish  attributes  from  different  domains 
by  writing  the  full  hierarchy  of  the  attribute  in  a  tuple.  Eor  example,  if  the  university 
created  a  “Student”  attribute,  that  attribute  would  be  written  ("University",  "Student").  If 
the  university  delegated  attribute  generation  authority  to  the  college  of  engineering,  and  the 
engineering  college  in  turn  created  a  “Student”  attribute,  it  would  be  written  ("University", 
"College  of  Engineering",  "Student").  As  with  the  multi-authority  example,  these  attributes 
could  be  combined  in  a  single  access  policy  that  would  require  a  student  to  have  credentials 
from  both  the  university  and  the  college  of  engineering.  Allowing  authorities  to  delegate 
the  ability  to  generate  attributes  in  an  autonomous  way  is  crucial  for  large  organizations. 
It  allows  for  the  maintenance  of  attribute  keys  to  be  managed  in  the  same  structure  as  the 
organization  itself. 

The  complexity  of  a  CP-ABE  system  such  as  MA-AHASBE  provides  a  great  deal 
of  expressiveness  in  protecting  the  confidentiality  and  integrity  of  data.  However,  this 
expressiveness  comes  at  a  cost.  MA-AHASBE  operations  are  typically  slower  than  AEAD 
or  even  KP-PKE  operations.  The  encryption  time  and  size  of  the  resulting  ciphertext  scales 
with  the  number  of  leaf  nodes  in  an  access  policy.  The  decryption  time  scales  with  the 
number  of  nodes  that  are  required  to  satisfy  the  policy.  As  such,  MA-AHASBE  is  used  in 
conjunction  with  AEAD  and  KP-PKE.  By  combining  MA-AHASBE  with  AEAD  and  KP- 
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PKE,  some  of  the  performance  cost  can  be  mitigated  while  maintaining  the  expressiveness 
ofMA-AHASBE. 

There  are  two  basic  ways  of  employing  MA-AHASBE.  The  first  way  is  shown  in 
Eigure  5.1.  The  shaded  portions  of  the  figure  indicate  data  that  is  meant  to  be  private, 
while  the  unshaded  portions  may  be  put  in  a  public  location  (such  as  a  public  cloud).  Here, 
MA-AHASBE  is  used  to  protect  a  symmetric  key  with  an  access  policy.  The  ciphertext 
produced  by  this  encryption  is  much  larger  than  the  original  message.  A  128-bit  symmetric 
key  encrypted  with  the  policy  shown  in  Eigure  5.1  may  result  in  ciphertext  size  of  a  few 
kilobytes  (experimental  results  are  discussed  in  more  detail  in  §5.5).  The  symmetric  key 
is  then  used  to  encrypt  the  document  using  AEAD  which  is  much  faster  and  produces 
ciphertext  that  is  close  in  size  to  the  original  message.  MA-AHASBE  and  AEAD  both 
protect  against  tampering  with  ciphertext.  Ciphertexts  that  are  not  the  result  of  following 
the  encryption  algorithms  will  produce  an  error  when  decryption  is  attempted,  as  opposed 
to  producing  an  incorrect  plaintext.  Decryption  reverses  the  process.  A  user  that  possess 
MA-AHASBE  attribute  keys  that  satisfies  the  policy  can  recover  the  symmetric  key.  This 
symmetric  key  can  then  be  used  to  recover  the  document. 

The  method  of  using  a  symmetric  key  directly  with  MA-AHASBE  is  useful  when  a 
policy  is  only  used  once.  When  a  policy  needs  to  be  used  with  multiple  documents,  it  can  be 
more  efficient  to  augment  the  approach  with  a  KP-PKE  system.  This  modified  encryption 
flow  is  shown  in  Eigure  5.2.  Here,  instead  of  using  MA-AHASBE  to  encrypt  a  symmetric 
key,  it  is  used  to  encrypt  the  private  key  of  a  KP-PKE  key  pair.  The  corresponding 
public  key  part  of  the  KP-PKE  key  pair  then  used  to  protect  the  symmetric  key.  The 
benefit  of  doing  this  is  that  to  encrypt  another  document  under  the  same  policy,  only 
KP-PKE  operations  are  needed.  KP-PKE  operations  can  be  much  more  efficient  than 
MA-AHASBE  operations,  especially  for  large  policies.  This  savings  is  carried  over  to 
decryption  operations  as  well. 
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Figure  5.1:  MA-AHASBE  encryption  flow  with  AEAD  only.  Shaded  portions  indicate 
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Figure  5.2:  MA-AHASBE  encryption  flow  with  KP-PKE  and  AEAD.  Shaded  portions 
indicate  private  data  and  dashed  arrows  indicate  the  result  of  an  encryption  operation. 


Hazelcast  Hazelcast  is  an  open  source  Java  project  that  provides  distributed,  in-memory 
data  structures  such  as  sets,  maps,  queues  and  topics. 

Sodium  Sodium  is  a  modem  reimplementation  of  the  NaCl  cryptographic  library.  It 
contains  implementations  of  a  wide  variety  of  cryptographic  primitives  such  as 
AEAD,  KP-PKE.  digital  signatures,  and  MAC.  The  project  is  open  source  and 
written  in  cross-platform  C.  Bindings  exist  for  a  variety  of  languages  including  Java, 
and  there  is  a  Javascript  build  that  has  been  compiled  with  the  Emscripten  cross- 
compiler. 
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SocketIO  SocketIO  is  a  protocol  for  establishing  real-time,  full-duplex,  event  based 
connections.  It  uses  WebSockets  as  the  primary  connection  protocol  with  a  fallback 
to  long  polling.  The  primary  project  is  open  source  and  provides  both  server  and 
client  implementations  written  in  Javascript.  There  are  other  open  source  projects 
which  provide  Java  clients  and  servers. 

5.3  Security  Model 

When  discussing  security  and  cloud  computing,  it  is  important  to  describe  who  is 
trusted  as  well  as  the  meaning  of  that  trust.  Many  protocols  related  to  secure  cloud 
computing  use  some  variation  of  the  hone st-but- curious  (HBC)  [27,  33,  59,  86,  87,  101] 
model  with  potentially  malicious  actors.  In  an  HBC  model,  HBC  actors  faithfully  follow 
the  underlying  protocol  but  remember  all  the  messages  they  see  and  attempt  to  violate 
privacy  if  they  can.  Malicious  actors  are  allowed  to  behave  however  they  like  (e.g.,  they 
may  lie,  cheat,  attempt  to  impersonate  others,  fail  to  participate). 

A  traditional  HBC  model  may  not  be  a  satisfying  security  model  for  cloud  computing. 
For  example,  there  may  be  instances  where  the  cloud  service  provider  (CSP)  can  reasonably 
be  expected  to  follow  some  protocols  in  an  HBC  fashion,  but  may  follow  other  parts 
of  the  protocol  as  a  malicious  actor.  For  example,  in  a  simple  protocol  that  only  stores 
and  retrieves  data  a  CSP  might  fall  under  an  HBC  model  where  it  is  expected  that  the 
stored  data  is  retrievable  at  some  point  in  the  future.  In  other  words,  it  is  reasonable  to 
believe  that  a  CSP  wouldn’t  maliciously  destroy  data  or  otherwise  make  it  unavailable. 
Realistically  though,  data  becomes  corrupted  despite  the  large  amount  of  effort  CSPs  put 
into  data  durability.  The  durability  of  the  data  is  usually  guaranteed  by  the  CSP  up  to  some 
small  amount  of  loss  specified  through  a  service  level  agreement.  Additionally,  while  any 
reasonable  CSP  wouldn’t  purposefully  tamper  with  data,  it  is  not  impossible.  Situations  can 
arise  such  as  malicious  employees,  or  third  party  attackers  gaining  control  of  the  CSP  and 
tampering  with  data.  If  we  model  the  CSP  in  this  storage  service  protocol  as  HBC,  we  may 
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not  be  accurately  capturing  the  fact  that  this  loss  occurs  and  we  may  be  making  any  other 
protocols  that  depend  on  this  protocol  vulnerable  to  attack.  While  this  seems  unsettling, 
modeling  the  CSP  as  malicious  doesn’t  seem  to  represent  reality  either.  If  the  CSP  is 
modeled  as  malicious,  the  CSP  may  arbitrarily  decide  to  make  the  data  unavailable  or  may 
make  changes  to  any  amount  of  data  it  wishes.  Modeling  the  CSP  as  purely  malicious 
seems  to  defeat  the  purpose  of  using  the  CSP  in  the  first  place. 

Instead,  we  propose  two  security  models  called  A-trusted  and  ACE-trusted  that  are 
still  conceptually  straightforward,  but  do  a  cleaner  job  of  separating  out  the  concerns  that 
are  unique  to  cloud  computing.  The  key  insight  is  that  when  data  is  stored  with  a  CSP,  an 
explicit  trust  relationship  is  formed  with  regard  to  availability  if  that  data  is  ever  expected 
to  be  retrieved  in  the  future.  Luckily,  the  core  business  model  of  most  CSPs  is  to  supply 
strong  availability  guarantees.  Accepting  this  trust  relationship  seems  unavoidable  when 
dealing  with  exporting  data  to  a  third  party.  However,  this  trust  does  not  necessarily  extend 
to  other  aspects  of  information  security  such  as  confidentiality  and  integrity.  The  goal  of  the 
A-trusted  and  ACE-trusted  security  models  is  to  more  accurately  capture  this  difference. 

5.3.1  The  A-trusted  and  ACE-trusted  Security  Models. 

What  is  needed  is  something  between  HBC  and  malicious.  We  could  perhaps  call 
this  middle  ground  semi-malicious,  but  this  seems  overly  vague  and  unintuitive.  Instead,  a 
clearer  approach  may  be  to  use  the  building  blocks  of  information  security:  confidentiality, 
integrity,  and  availability.  The  NIST  definitions  for  these  terms  are  listed  below  [81]: 

Confidentiality  Confidentiality  is  the  requirement  that  private  or  confidential  information 
not  be  disclosed  to  unauthorized  individuals.  Confidentiality  protection  applies  to 
data  in  storage,  during  processing,  and  while  in  transit. 
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Integrity  Integrity  can  be  one  of  two  types: 

Data  Integrity  The  property  that  data  has  not  been  altered  in  an  unauthorized 
manner  while  in  storage,  during  processing,  or  while  in  transit. 

System  Integrity  The  quality  that  a  system  has  when  performing  the  intended 
function  in  an  unimpaired  manner,  free  from  unauthorized  manipulation. 

Availability  Availability  is  a  requirement  intended  to  assure  that  systems  work  promptly 
and  service  is  not  denied  to  authorized  users.  This  objective  protects  against: 

•  Intentional  or  accidental  attempts  to  either: 

-  perform  unauthorized  deletion  of  data 

-  cause  a  denial  of  service  or  data. 

•  Attempts  to  use  system  or  data  for  unauthorized  purposes 

Although  not  part  of  the  official  NIST  definition,  it  may  be  helpful  to  view  the 
components  of  confidentiality  in  terms  of  the  popular  information  gathering  rules  of  five  VTs 
and  one  H  or  5W1H.  Even  though  many  encryption  oriented  security  solutions  only  focus 
on  the  what  component  in  terms  of  confidentiality,  protecting  each  method  of  information 
gathering  typically  incurs  some  type  of  performance  cost.  Any  proposed  solution  dealing 
with  secure  cloud  computing  should  address  which  components  of  5W1H  are  explicitly 
supported  and  which  ones  are  assumed.  For  the  applications  in  this  research,  only  the  what 
aspect  of  confidentiality  is  supported.  Each  component  of  5W1H  is  listed  here: 

Who  is  the  source  that  generated  the  information 
What  is  the  content  of  the  information 
When  was  the  information  generated 
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Where  is  the  geographic  or  logical  location  in  a  network  of  the  entity  that  generated  the 
data 

Why  was  the  information  produced  or  which  events  trigger  its  creation 
How  is  the  data  protected  (i.e.,  what  is  the  encryption  scheme  or  protocol) 

As  with  confidentiality,  it  may  be  helpful  to  break  the  definition  of  integrity  down 
into  more  familiar  parts.  Here  we  consider  data  integrity  to  consist  of  two  components: 
corruption  and  authentication.  Corruption  occurs  when  a  value  is  changed  outside  a 
predetermined  computation  or  protocol.  This  occurs  benignly  in  variety  of  situations 
such  as  component  failure  in  storage  drives  or  transmission  hardware.  If  the  source 
of  the  corruption  is  benign,  it  can  be  detected  with  techniques  such  as  checksums  or 
hash  functions.  Malicious  corruption  requires  different  techniques  such  as  message 
authentication  codes  or  digital  signatures.  Authentication  is  the  process  of  certifying  a 
value  with  a  set  of  credentials  along  with  the  process  of  verifying  the  certification.  This  is 
critical  to  scenarios  where  validating  the  source  of  the  information  is  as  important  as  the 
data  itself. 

Finally,  it  is  also  helpful  to  examine  the  components  of  availability.  One  popular  data 
storage  model  consists  of  the  operations  Create,  Read,  Update,  Delete  (CRUD).  Variations 
of  this  model  include  Browse,  Read,  Edit,  Add,  Delete  (BREAD)  and  Delete,  Read, 
Update,  Eock,  Add,  Browse  (DRUEAB).  The  CRUD  model  seems  to  be  the  closest  fit 
that  is  parsimonious  and  captures  the  basic  functions  of  CSP  availability.  However,  in 
some  ways  CRUD  does  not  perfectly  align  with  how  we  may  want  to  view  CSP  availability 
operations  in  our  security  model.  Eor  example,  if  a  delete  operation  is  sent  to  the  CSP, 
there  is  generally  no  way  for  the  client  to  know  if  the  information  is  truly  (or  securely) 
being  deleted.  Requiring  that  the  data  is  actually  deleted  may  capture  more  trust  than  we 
actually  require  or  expect  from  a  CSP.  A  delete  operation  to  a  CSP  is  really  just  way  for 
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the  client  to  inform  the  CSP  that  it  no  longer  needs  access  to  the  data  and  that  it  should  no 
longer  be  charged  by  the  CSP  to  make  it  available.  This  is  weaker  than  the  assumption  that 
the  CSP  actually  deletes  the  data  upon  request,  and  arguably  more  accurately  captures  the 
trust  relationship.  Therefore,  in  order  to  facilitate  a  more  fine-grained  discussion  of  what 
services  a  CSP  is  responsible  to  provide,  we  present  the  Function,  Search,  Create,  Read, 
Annul,  Write,  Lock  (F-SCRAWL)  model. 

Function  The  client  submits  a  computation  request  to  the  CSP  and  the  CSP  returns  a  result 
that  can  be  verified  as  correct  by  the  client  more  efficiently  than  simply  performing 
the  computation  directly. 

Search  The  client  may  present  a  query  (e.g.,  SQL  or  NoSQL)  to  the  CSP  and  the  CSP  will 
return  the  subset  of  valid  data  that  matches  the  query  parameters. 

Create  The  client  requests  that  a  datum  be  stored  and  marked  as  valid  for  later  operations. 

Read  The  client  requests  access  to  the  current  value  of  a  datum  that  has  previously  been 
stored  with  the  Create  operation. 

Annul  The  client  marks  a  datum  as  invalid  and  will  no  longer  perform  operations  for  this 
datum  (i.e.,  any  future  operations  for  this  datum  should  be  considered  invalid). 

Write  The  client  wishes  to  update  an  datum  previously  stored  with  the  Create  operation 
to  a  new  value  (could  include  concurrency  primitives  such  as  compare  and  swap). 

Lock  The  client  wishes  to  prevent  other  clients  access  (e.g..  Read,  Write,  Lock,  Annul) 
to  a  datum  previously  stored  with  the  Create  operation  until  the  lock  is  released 
(either  by  the  client  or  the  CSP). 

While  the  CRAWL  portion  of  F-SCRAWL  seems  directly  applicable  to  the  availability 
aspect  of  a  CSP,  it  may  not  be  as  clear  for  function  and  search  operations.  The  function 
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operation  has  been  carefully  defined  to  only  allow  computation  which  can  be  efficiently 
verified  as  correct  by  the  client  (e.g.,  the  result  of  running  a  secure,  multiparty  computation 
protocol).  This  condition  is  what  makes  the  function  operation  an  availability  operation 
rather  than  an  integrity  operation.  If  the  CSP  deviates  from  the  computation  protocol  or 
returns  an  incorrect  answer  (violating  system  integrity  as  defined  above),  then  the  client 
detects  this  and  discards  the  result.  If  this  occurs  with  a  high  enough  frequency,  the  CSP  is 
viewed  as  not  being  available  enough  for  computation  purposes.  Search  is  another  subtle 
operation  that  requires  availability  trust.  Here  the  trust  is  not  in  the  correctness  of  the 
returned  results  (which  can  be  verified  by  the  client),  but  in  that  the  returned  set  is  complete. 
Removing  this  trust  would  require  the  client  to  verify  that  the  CSP  is  returning  all  data  (i.e., 
making  it  available)  that  matches  the  query.  This  could  of  course  be  done  if  all  the  data  was 
also  stored  client  side,  but  this  may  defeat  the  purpose  of  storing  data  with  a  CSP  in  the 
first  place.  It  is  difficult  to  provide  this  for  a  general  data  set  and  set  of  queries,  therefore 
we  make  it  part  of  the  trusted  CSP  protocol. 

With  a  more  precise  view  of  the  CIA  model,  we  now  consider  what  type  of  trust  we 
need  to  place  in  a  CSP.  We  argue  that  the  only  trust  we  should  put  into  a  CSP  is  in  the 
availability  of  F-SCRAWL  operations.  Outsourcing  data  and  services  to  a  CSP  requires 
some  level  of  availability  trust.  In  a  sense,  we  are  narrowing  the  scope  of  the  CSP  to  be 
HBC  only  with  respect  to  F-SCRAWL  operations.  In  other  words,  the  user  trusts  that  the 
CSP  will  not  recklessly  destroy,  corrupt,  or  otherwise  make  the  data  unavailable.  Some 
data  loss  or  service  failure  will  occur  naturally  due  to  disasters,  hardware  failures  or  denial- 
of-service  attacks.  The  rate  at  which  this  is  expected  to  occur  will  generally  be  outlined  in 
the  service  level  agreement  (SLA)  of  the  CSP.  Also,  conformance  to  the  SLA  is  something 
that  can  be  monitored  by  the  client  assuming  the  client  is  checking  the  integrity  of  the  data 
returned  by  the  CSP.  If  the  risk  as  stated  in  the  SLA  is  too  high  or  if  the  CSP  is  not  abiding 
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by  the  SLA,  one  mitigation  approach  would  be  to  replicate  the  data  or  services  amongst 
multiple  CSPs. 

With  the  F-SCRAWL  model  in  place,  we  can  now  more  precisely  talk  about  what 
types  of  trusted  systems  play  a  role  in  a  secure  cloud  computing  scenario.  We  divide  the 
trust  levels  into  three  paradigms:  fully  trusted,  A-trusted  (with  ACE-trusted  as  a  special 
case),  and  malicious.  Each  paradigm  is  listed  below  along  with  a  short  description: 

Fully  trusted  (or  CIA-trusted)  A  fully  trusted  system  is  one  where  sensitive  plaintext 
data  such  as  cryptographic  keys,  personally  identifiable  information  (PII),  or  sensitive 
business  data  may  be  stored  in  plaintext  (either  on  disk  or  in  memory). 

Examples: 

•  Client  systems  of  authenticated  users 

•  Servers  deployed  in  a  private  cloud 

Availability-trusted  (or  A-trusted)  An  availability-trusted  system  will  faithfully  follow 
data  availability  protocols  (E-SCRAWE)  and  fulfill  availability  SEAs.  However,  it 
will  exploit  sensitive  data  to  which  it  has  access  but  does  not  require  in  order  to 
perform  its  duties  (i.e.,  violates  confidentiality).  It  will  manipulate  data  available  to  it 
in  order  to  accomplish  its  goals  if  the  data  manipulation  cannot  be  easily  detected  by 
the  data  owner  (i.e.,  violates  integrity).  If  the  system  is  Availability- Computability- 
Enforceability-trusted  or  ACE-trusted,  the  system  is  trusted  to  maintain  system 
integrity  with  respect  to  computations  it  is  asked  to  perform  as  well  as  enforce  access 
control  rules  it  receives  with  respect  to  third  parties.  The  CSP  will  still  attempt  to 
exploit  the  data  it  receives  if  it  can,  but  will  accept  and  enforce  rules  regarding  how 
third  parties  may  use  the  E-SCRAWE  protocols.  ACE-trusted  is  a  special  case  of 
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A-trusted. 


Examples: 

•  Servers  deployed  in  a  public  or  community  cloud 

•  Public  CSPs  may  be  considered  ACE-trusted  while  a  peer-to-peer  network 
may  be  considered  only  A-trusted 

•  Authenticated  users  who  wish  to  collude  to  access  information  to  which 
they  would  not  otherwise  have  access 

Malicious  Malicious  entities  are  willing  to  break  protocols  and  subvert  systems  in  order 
to  gain  access  to  information  or  systems.  Malicious  users  may  be  internal  or 
external.  Internal  malicious  users  are  those  who  abuse  legitimate  access  to  systems 
or  cryptographic  keys.  External  malicious  users  do  not  have  legitimate  access  to 
systems  or  cryptographic  keys  and  use  a  variety  of  techniques  to  bypass  security 
mechanisms. 

Examples: 

•  Everyone  else 

•  Evil  hackers 

•  Insider  threat 

5.4  Axon:  A  Data  Structure  Approach  to  Security,  Scalability  and  Dependability 

In  order  to  bridge  the  gap  between  the  ACE-trusted  security  model  and  applications, 
we  built  a  framework  to  facilitate  the  communication  between  an  application  and  a  CSP 
This  framework  is  called  Axon^.  This  section  discusses  the  design  decisions  behind  Axon 
and  how  it  supports  the  ACE-trusted  security  model. 

^The  name  Axon  comes  from  the  nerve  fibers  that  connect  neurons  inside  the  brain  and  act  as  information 
transmission  pathways 


97 


5.4.1  Architecture. 


By  design,  Axon  is  a  very  small  interface  from  the  perspective  of  an  application.  In 
fact,  in  order  to  support  the  applications  described  in  the  next  section,  only  three  data 
structures  are  used.  Each  data  structure  has  a  small  number  of  functions  that  can  be  called. 
These  data  structures  become  the  only  interface  between  the  application  code  and  the  CSP. 
The  data  structures  used  for  the  applications  in  described  in  the  next  section  are  shown  in 
Table  5.1. 


Table  5.1:  Axon  Data  Structures 


Data  Structure 

Example  Functions 

Map 

insert,  update,  remove,  lookup,  enumerate-keys 

Queue 

enqueue,  dequeue 

Topic 

publish,  subscribe,  lookup 

Focusing  on  a  small  set  of  data  structures  as  the  key  interface  between  the  application 
and  the  cloud  provides  a  number  of  key  benefits.  First,  it  removes  the  responsibility  of 
scaling  and  durability  away  from  the  application  code.  From  the  application’s  perspective, 
any  data  stored  into  the  Axon  data  structures  is  expected  to  be  highly  available.  Secondly, 
since  there  are  only  a  few  ways  to  store  data,  applications  have  fewer  places  to  check 
to  make  sure  that  data  is  properly  protected.  However,  the  restriction  to  these  data  sets 
along  with  the  condition  that  any  information  placed  inside  them  must  be  encrypted  puts 
some  additional  complexity  burden  on  the  applications.  Techniques  for  dealing  with  this 
complexity  are  discussed  in  the  next  section. 

The  overall  information  flow  for  an  Axon  enabled  application  is  shown  in  Figure 
5.3.  Cryptographic  keys  begin  their  life  within  a  private  cloud  infrastructure  that  supports 
a  hierarchy  of  private  key  generators.  These  private  key  generators  distribute  keys 
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Figure  5.3:  Axon  Information  Flow 


representing  user  attributes  to  each  of  the  users  in  the  system.  Users  provide  their  keys 
to  Axon  enabled  applications  where  any  information  that  is  stored  in  Axon  data  structures 
is  required  to  be  encrypted.  The  client  side  of  the  Axon  framework  then  takes  the  request 
and  sends  it  across  a  public  channel  (e.g.,  the  Internet)  to  a  Hazelcast  server  over  a  SocketIO 
connection.  These  requests  consist  of  a  data  type  (e.g.,  topic,  map,  queue),  the  data 
structure’s  name  as  a  string  (e.g.,  “parameters”,  “users”),  the  name  of  the  function  (e.g,. 
add.  remove),  and  any  required  function  parameters.  When  the  cluster  receives  the  request, 
it  must  determine  if  the  client  is  authorized  to  perfonn  that  operation  on  that  specific  data 
structure. 

In  the  current  prototype  implementation  of  Axon,  all  users  are  allowed  to  create  data 
structures  as  long  as  the  name  for  the  data  structure  doesn’t  already  exist.  The  creator  of 
the  data  structure  specifies  the  permissions  for  each  operation  that  the  data  structure  allows. 
The  creator  does  this  by  generating  a  unique  KP-PKE  key  pair  for  each  function.  In  the 
request,  the  name  of  the  function  is  bound  to  the  public  portion  of  the  key  pair.  The  private 
key  is  encrypted  using  attribute-based  encryption  and  is  also  included  in  the  request.  When 
the  creator  sends  the  request,  it  includes  for  each  function  the  public  key,  the  protected 
private  key,  along  with  a  authorization  session  timeout  value.  When  the  cluster  receives  the 
request,  it  creates  the  requested  data  structure  along  with  a  permissions  map.  The  public 
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key,  protected  private  key  pair  and  timeout  value  are  stored  in  this  permission  maps.  When 
requests  come  into  the  cluster  to  perform  operations  on  the  data  structure,  the  cluster  first 
looks  to  see  if  the  client  has  an  active  authorization  session.  If  this  is  the  first  time  this 
client  has  requested  to  do  an  operation  on  a  specific  data  structure  or  the  clients  previous 
session  has  reached  its  timeout  value,  then  it  will  not  have  an  active  authorization  session. 
The  server  will  look  up  the  public  key  for  the  operation  and  encrypt  a  random  value  (also 
called  a  nonce,  or  number  used  once)  with  that  public  key.  It  will  then  send  this  encrypted 
nonce  along  with  the  protected  private  key  to  the  client.  If  the  client  is  able  to  satisfy  the 
policy  associated  with  the  protected  private  key,  it  is  able  to  recover  the  private  portion  of 
the  KP-PKE.  It  can  then  use  this  private  key  to  recover  the  random  nonce  sent  by  the  server. 
It  returns  this  value  to  the  server,  and  if  the  value  matches  the  random  nonce  that  the  server 
originally  sent  the  client,  an  authorization  session  is  created  and  timestamped.  The  client 
is  then  allowed  to  perform  the  associated  function  until  the  session  reaches  the  timeout 
specified  in  the  creation  request.  An  example  of  the  message  exchanges  involved  in  the 
creation  of  a  data  structure  as  well  as  a  client  gaining  authorization  to  perform  a  function 
is  shown  in  Figure  5.4. 

This  protocol  serves  as  a  good  example  of  the  difference  between  the  A-trusted  and 
ACE-trusted  security  models.  Under  the  A-trusted  security  model,  the  CSP  would  not  be 
bound  by  this  authorization  protocol  and  would  be  free  to  fulfill  data  requests  from  any 
client.  Therefore,  under  an  A-trusted  model,  additional  measures  must  be  taken  to  enforce 
these  types  of  permissions.  For  example,  to  enforce  a  “write”  type  permission  clients  could 
include  a  signature  on  all  stored  data  that  represented  a  “write”  permission  attribute  using  an 
attribute -based  signature  scheme.  Clients  accessing  the  data  structure  would  only  consider 
the  data  valid  if  it  contains  a  proper  signature.  The  choice  of  security  model  is  of  course 
application  and  client  specific,  but  we  believe  that  the  ACE-trusted  security  model  provides 
the  right  balance  for  many  situations. 
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Figure  5.4:  Example  Session  for  Data  Structure  Creation  and  Authorization  Protocols 
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The  current  implementation  of  Axon  is  built  on  top  of  Amazon’s  Web  Services  (AWS) 
public  cloud  infrastructure.  Many  cloud  providers,  including  Amazon,  provide  services 
that  support  the  data  structures  selected  in  Axon.  For  example,  Amazon  provides  a  service 
called  Simple  Notification  System  (SNS)  that  would  support  some  aspects  of  the  topic 
data  structure.  However,  there  are  some  drawbacks  with  using  this  service.  First,  users 
are  limited  to  only  3,000  topics  without  additional  authorization  from  Amazon.  In  our 
microblogging  application,  a  unique  topic  is  required  for  each  tag  and  user.  In  order  to 
provide  this  capability.  Axon  uses  the  Hazelcast  project  to  provide  distributed  versions  of 
each  structure  (map,  queue,  topic).  Changes  to  these  data  structures  are  communicated  to 
and  from  any  connected  clients  via  the  SocketIO  protocol  as  shown  in  Figure  5.3. 

Since  the  Axon  framework  does  not  rely  on  the  built-in  cloud  provider  services  for  the 
data  structures,  it  must  still  remain  dependable  even  in  when  the  entire  processing  cluster 
fails.  Since  Hazelcast  is  an  in-memory  distributed  system,  failure  of  the  cluster  would 
result  in  complete  data  loss.  Fortunately,  Hazelcast  provides  a  persistance  API  for  maps 
and  queues.  In  Axon,  this  persistance  API  is  connected  to  the  database  and  storage  services 
provided  by  Amazon.  DynamoDB  is  a  NoSQL  database,  and  this  is  the  primary  destination 
for  items  inserted  into  maps  and  queues. 

5.5  Applications 

This  section  describes  how  the  basic  data  structures  in  the  Axon  framework  are  layered 
to  create  a  secure  microblogging  application.  The  first  example  demonstrates  how  to 
take  the  map  data  structure  provided  by  Axon  and  enhance  it  to  be  compatible  with  the 
ACE-trusted  security  model.  The  next  example  demonstrates  how  to  build  a  ACE-trusted 
remote  procedure  call  protocol  using  Axon  data  structures.  Einally,  these  relatively  simple 
building  blocks  are  used  to  build  a  more  complex  messaging  application  called  Critter. 
This  messaging  application  is  compatible  with  the  ACE-trusted  security  model,  and  could 
be  used  as  a  building  block  in  even  more  complex  applications. 
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5.5.1  Secure  Map. 

The  secure  map  data  structure  interfaces  with  the  regular  map  data  structure  provided 
by  Axon  and  provides  all  of  the  same  functions.  The  difference  is  that  the  secure  map 
is  initialized  with  a  symmetric  cryptographic  key.  The  secure  map  uses  this  key  in  order 
to  provide  confidentiality  and  integrity  guarantees  to  the  data  that  passes  through  it.  As  a 
result,  the  secure  map  supports  the  ACE-trusted  security  model. 

The  secure  map  protects  all  three  portions  of  a  map:  the  map  name,  index  keys"^,  and 
values.  When  performing  map  functions,  the  secure  map  will  first  compute  a  MAC  (using 
the  cryptographic  key  provided  to  the  secure  map)  of  the  plaintext  map  name  to  create  a 
secure  map  name.  This  secure  map  name  is  then  used  to  perform  operations  on  a  regular 
map  data  structure.  When  performing  a  put  operation,  the  secure  map  must  protect  both  an 
index  key  and  a  value.  To  protect  the  index  key,  a  MAC  is  computed  for  the  plaintext  index 
key  and  used  as  the  secure  index  key.  Since  the  MAC  function  is  deterministic,  plaintext 
index  keys  will  always  map  the  same  secure  index  keys  as  long  as  the  cryptographic  key 
is  the  same.  Then  both  the  index  key  and  the  value  are  each  encrypted  using  AEAD, 
concatenated  with  a  separating  delimiter,  and  stored  as  the  secure  value.  The  reason  that 
the  index  key  is  encrypted  and  stored  alongside  the  encrypted  value  is  to  support  index  key 
enumeration  operations.  Since  a  MAC  is  used  as  the  secure  key,  there  is  no  way  to  “undo” 
the  MAC  operation  to  recover  the  plaintext  key.  Instead,  the  secure  map  performs  a  key 
enumeration  on  underlying  map  to  get  a  set  of  secure  key  values.  The  secure  map  can  than 
get  each  secure  index  key’s  respective  secure  value.  Einally,  the  secure  map  can  decrypt  the 
secure  index  key  portion  of  the  secure  value,  thereby  recovering  the  plaintext  index  keys. 
To  perform  get  operations,  the  secure  key  is  computed  like  before  which  returns  the  secure 
value.  The  secure  map  can  decrypt  the  encrypted  value  portion  of  the  secure  value. 

^In  order  to  avoid  confusion,  we  use  the  terms  cryptographic  key  and  index  key  to  refer  to  keys  used  for 
encryption  operations  and  map  operations  respectively 
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Through  the  use  of  a  cryptographic  key,  the  secure  map  is  able  to  provide 
confidentiality  and  integrity  guarantees.  The  availability  of  the  map  contents  is  supported 
through  the  Axon  interface  to  the  cloud  infrastructure.  This  demonstrates  a  simple  example 
of  building  an  ACE-trusted  data  structure  from  one  of  the  basic  data  structures  provided  by 
Axon.  For  an  application  using  a  secure  map,  the  focus  is  shifted  to  acquiring  the  right  set 
of  cryptographic  keys  and  not  the  mechanics  of  how  the  data  is  protected  or  stored. 

5.5.2  Secure  Remote  Procedure  Call. 

In  addition  to  creating  secure  data  structures  from  the  core  data  structures,  it  is  also 
possible  to  build  secure  protocols.  One  example  is  a  simple  remote  procedure  call  (RPC) 
protocol  that  leverages  the  queue  data  structure  provided  by  Axon.  The  message  sequence 
for  this  protocol  is  shown  in  Figure  5.5.  Just  like  the  secure  map,  the  secure  RPC  protocol  is 
initialized  with  a  set  of  cryptographic  keys.  The  keys  allow  the  protocol  to  protect  the  data 
when  sending  and  receiving  data  from  the  Axon  queues.  The  queues  then  provide  a  layer 
of  availability  and  durability.  The  current  use  case  for  the  secure  RPC  mechanism  is  for  a 
pool  of  remote  servers  that  share  a  common  KP-PKE  key  pair.  Any  of  these  remote  servers 
is  capable  of  fulfilling  a  request.  Each  local  instance  generates  its  own  unique  KP-PKE 
pair.  The  protocol  supports  at  least  once  semantics  and  resubmits  requests  after  a  specified 
timeout  period.  In  addition  to  the  execute  function,  a  broadcast  function  is  available  simply 
by  replacing  queues  with  topics.  Permission  to  execute  functions  can  leverage  the  same 
authentication  protocol  as  the  one  described  for  data  structure  creation.  Note  that  the 
remote  server  does  not  require  private  keys  in  order  to  authenticate  a  request,  so  instances 
of  the  remote  server  may  run  on  the  cloud  infrastructure  as  long  as  the  requested  procedure 
call  does  not  require  access  to  plaintext  data. 

5,5.5  Micro-Messaging. 

Now  that  we  have  described  some  of  the  building  blocks,  we  now  describe  the 
structure  of  a  relatively  simple  messaging  application  called  Critter.  Critter  supports  the 
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Figure  5.5:  Secure  RPC  Message  Sequence 
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basic  messaging  capabilities  of  popular  microblogging  applications  such  as  Twitter  and 
Instagram.  Each  user  has  a  public  feed  to  which  followers  can  subscribe.  Users  may  tag 
messages  by  including  the  hashtag  symbol  #  followed  by  a  keyword  of  the  user’s  choice. 
We  refer  to  these  hashtag  keywords  as  topics.  Users  may  then  follow  these  tags  for  topics 
which  interest  them.  Users  may  also  direct  messages  to  only  be  sent  to  specific  users  rather 
than  their  public  feed  by  including  the  target  users’  handle  preceded  by  the  @  symbol. 
We’ll  re 


Figure  5.6:  Critter  Information  Flow 


The  structure  of  the  Critter  application  is  shown  in  Figure  5.6.  The  highlighted 
portions  indicate  where  Critter  uses  Axon  data  structures  directly  rather  than  relying  on 
secure  components.  When  the  critter  application  is  first  started  and  before  any  messages 
are  sent,  a  small  set  of  public  data  is  stored  in  an  unsecure  map.  This  map  contains  the 
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information  needed  to  bootstrap  the  security  for  the  rest  of  the  system  and  consists  of  the 
following: 

•  A  public  random  value  used  when  creating  private  keys  from  passwords  (also  known 
as  a  salt) 

•  The  public  parameters  for  the  CP- ABE 

•  A  private  key  that  has  been  encrypted  using  a  CP-ABE  policy  that  requires  the 
“CritterUser”  attribute 

Whenever  a  new  user  is  created,  that  user  receives  an  the  “CritterUser”  attribute  from  the 
private  key  generator.  This  process  is  assumed  to  happen  out-of-band.  When  a  user  logs 
into  the  system,  the  user  can  use  this  attribute  to  recover  the  CP-ABE  protected  private 
key  stored  in  the  public  map.  This  key  is  used  in  a  few  places  within  the  application. 

Specifif'a11v  it  is  used  tn  arress  the,  sernre,  man  where,  the  messapes  are  stored 


Eigure  5.7:  General  Critter  Message  Policy  Structure 
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Figure  5.8:  Example  message  mapped  to  security  policy 


When  a  user  sends  a  message,  the  application  first  parses  the  message  to  determine 
if  it  contains  any  topics  or  if  the  message  is  directed  to  specific  users.  If  the  message 
has  any  mentions,  the  message  is  considered  to  be  private  and  the  relevant  users  are 
considered  mentioned  in  the  message.  If  there  are  no  mentions,  the  message  is  public. 
If  the  message  contains  topics,  then  the  message  is  restricted.  Otherwise  the  message 
is  unrestricted.  Critter  uses  this  information  to  build  the  MA-AHASBE  policy  based  on 
the  general  structure  shown  in  Eigure  5.7.  If  the  message  is  private,  all  of  the  user  handles, 
including  that  of  the  sender,  are  combined  in  under  an  OR  node  in  the  policy.  If  the  message 
is  restricted,  then  the  topics  are  combined  under  an  AND  node.  Einally,  all  messages 
include  the  “CritterUser”  attribute.  This  attribute  is  particularly  useful  for  unrestricted. 
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public  messages.  In  this  case,  the  “CritterUser”  attribute  is  the  only  one  in  the  policy  and 
is  used  to  provide  a  baseline  policy  to  protect  the  information  from  the  CSP.  The  policy 
enforces  the  condition  that  in  order  to  decrypt,  a  user  must  possess  as  attributes: 

•  at  least  one  of  the  handles  used  in  the  message  (if  any  are  used) 

•  all  of  the  topics  in  the  message  (if  any  are  used) 

•  the  “CritterUser”  attribute 

This  policy  forces  users  to  have  all  of  the  tagged  topics  as  attributes  in  order  to  decrypt  a 
message.  In  Critter,  this  is  a  way  to  control  who  has  access  to  certain  topics  of  conversation. 

Once  the  policy  is  built.  Critter  uses  MA-AHASBE  to  create  a  corresponding 
ciphertext.  A  universally  unique  identifier  (UUID)  is  generated  for  the  ciphertext  and  the 
encrypted  message  is  stored  in  a  secure  message  map  with  the  UUID  as  the  index  key.  If 
the  message  is  public,  the  message  UUID  is  then  posted  to  the  user’s  feed,  which  is  an 
Axon  topic.  Any  followers  of  this  user  will  then  receive  the  UUID  and  can  then  retrieve 
the  message  from  the  secure  map.  If  the  message  is  private,  the  UUID  is  instead  sent  to  an 
Axon  queue  for  each  user  mentioned  in  the  message. 

Critter  uses  the  secure  RPC  mechanism  described  in  the  previous  section  in  order  to 
request  and  receive  attribute  keys  from  the  private  key  generator.  Whenever  a  user  receives 
a  message  with  topics  it  does  not  have  attributes  for,  it  issues  a  key  request  to  the  private  key 
generator.  The  private  key  generator  determines  if  the  user  is  allowed  to  access  messages 
with  the  request  topic.  If  so,  the  PKG  generates  a  key  and  sends  it  back  to  the  user.  If  not, 
a  message  is  sent  denying  the  request. 

Consider  the  example  shown  in  Figure  5.8.  In  this  example,  a  user  Alice  with 
the  handle  ©alice  publishes  the  message  “©bob  What’s  the  status  o£  today’s 
climate  assessment?  #sensitive  #humanResources”.  This  is  a  private,  restricted 
message.  Critter  builds  the  policy  shown  in  Figure  5.8,  generates  and  stores  the  ciphertext 
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in  the  secure  message  map  with  a  fresh  UUID  as  the  key,  and  finally  adds  the  message 
to  a  queue  named  “©bob. mentions”.  Whenever  Bob  comes  online,  he  can  check  his 
queue  and  retrieve  the  message.  If  he  can  satisfy  the  policy,  he  can  then  recover  the 
message.  If  not,  he  will  send  a  request  to  the  PKG  for  any  missing  attributes.  Suppose 
Alice  instead  wanted  to  send  the  message  to  anyone  following  her  feed.  In  this  case,  Alice 
would  remove  the  mention  “©bob”  from  the  message.  The  resulting  policy  would  then  not 
contain  any  mentions.  The  UUID  would  be  sent  to  Alice’s  feed  topic  “©alice .  feed”. 
Any  followers  would  then  receive  the  UUID  and  attempt  the  same  decryption  process  as 
previously  described  with  Bob. 

5.5.4  Experimental  Results. 

In  this  section,  we  examine  the  performance  characteristics  of  Axon  and  Critter.  The 
performance  can  be  be  viewed  from  two  perspectives.  First,  we  look  at  the  performance 
impact  to  the  user  in  terms  of  encryption  and  decryption  time.  Second  we  look  at  the  impact 
from  the  server  perspective,  specifically  in  the  requirement  to  support  the  larger  payloads 
associated  with  encrypting  the  data  using  MA-AHASBE.  In  order  to  do  this,  we  analyzed 
a  sample  set  of  450,000  messages  from  the  Twitter  message  service.  All  experiments  were 
performed  on  machines  running  Windows  7  with  Intel  Xeon  X5675  6-core  processors  and 
32  GB  of  RAM  connected  on  a  local  area  network. 

As  described  in  the  previous  section,  the  number  of  topic  tags  and  mention  tags 
determines  the  size  of  the  access  policy  for  a  particular  message.  The  size  of  the  access 
policy,  in  turn,  influences  the  size  of  the  ciphertext  created  by  MA-AHASBE.  The  sample 
database  was  analyzed  to  determine  how  many  topic  and  mention  tags  occur  in  a  message. 
Some  summary  information  is  presented  in  Table  5.2.  The  table  shows  the  number  of  topics 
and  mentions  in  terms  of  percentiles.  Eor  example,  99%  of  all  the  messages  in  the  sample 
contain  five  topic  tags  or  less.  The  largest  number  of  topics  in  any  single  tweet  was  17.  Eor 
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mention  tags,  99%  of  messages  have  six  or  less  while  the  largest  for  a  single  message  was 
14.  The  final  row  shows  the  counts  when  both  types  of  tags  are  combined. 


Table  5.2:  Summary  Statistics 


Category 

50th  percentile 

95th  percentile 

99th  percentile 

Max 

Topics 

0 

2 

5 

17 

Mentions 

1 

2 

6 

14 

Combined 

1 

4 

7 

17 

Another  way  to  look  at  how  the  tags  occur  within  a  message  is  shown  in  Figures  5.9 
and  5.10.  These  figures  shown  the  percentiles  of  how  many  tags  occur  with  respect  to 
one  another.  In  both  figures,  we  see  that  there  is  a  substantial  drop  between  the  maximum 
count  relative  to  the  99%  percentile  case.  This  is  particularly  true  when  there  are  either  zero 
mention  or  zero  topic  tags.  When  there  are  zero  topic  tags,  the  largest  observed  number 
of  mention  tags  was  14,  but  99%  of  messages  had  five  mentions  or  less.  When  there  are 
zero  mention  tags,  the  largest  observed  number  of  topic  tags  was  17,  but  99%  of  messages 
had  six  mentions  or  less.  The  data  also  reflects  the  fixed  140  character  limit  of  Twitter 
messages.  As  the  number  of  topic  tags  increase  in  a  message,  the  number  of  mentions 
decrease. 

The  number  and  type  of  tags  in  a  message  influence  the  amount  of  time  to  perform 
encryption  and  decryption  operations.  For  encryption  operations,  the  performance  scales 
with  the  total  number  of  tags.  The  performance  of  the  encryption  operation  is  shown  in 
Figure  5.11.  The  format  of  the  figure  follows  the  format  of  Figure  5.9  where  each  line 
represents  the  percentile  of  mentions  per  topic.  As  shown  in  Table  5.2,  99%  of  messages 
have  five  topics  or  less.  In  Figure  5.1 1  we  see  that  for  messages  with  five  topics,  encryption 
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Figure  5.9:  The  number  of  mentions  in  a  tweet  per  the  number  of  tags  based  on  percentiles. 
For  example,  of  all  the  sample  tweets  with  exactly  two  topic  tags,  95%  have  three  mention 
tags  or  less  and  99%  have  six  mention  tags  or  less.  All  sample  tweets  with  two  topic  tags 
had  ten  mentions  or  less. 


time  time  is  typically  at  most  around  85  milliseconds.  As  the  number  of  topics  increase 
towards  the  maximum,  the  lines  converge  since  there  are  fewer  mention  tags  contributing 
to  the  total.  The  worst  case  encryption  times  are  under  140  milliseconds.  The  decryption 
timings  are  shown  in  Figure  5.12.  There  is  a  clear  linear  scaling  with  the  number  of  topics, 
but  there  is  not  much  variation  with  the  number  of  mentions.  Recall  that  the  security  policy 
is  built  by  combining  the  mention  tags  under  an  OR  gate  and  the  topic  tags  under  an  AND 
gate  (see  Figure  5.7).  The  decryption  time  scales  with  the  number  of  nodes  required  for 
decryption,  so  even  though  there  may  be  several  mention  tags  only  one  is  required  for 
decryption.  It  is  also  of  note  that  the  decryption  time  is  an  order  of  magnitude  larger  for 
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Topic  per  Mention 


Figure  5.10:  The  number  of  topic  tags  in  a  tweet  per  the  number  of  mentions  based  on 
percentiles.  For  example,  of  all  the  sample  tweets  with  exactly  two  mention  tags,  95% 
have  three  mention  tags  or  less  and  99%  have  five  mentions  or  less.  All  sample  tweets  with 
two  mentions  had  14  topic  tags  or  less. 


decryption  versus  encryption.  This  is  due  to  an  expensive  mathematical  operation  called 
a  bilinear  pairing  that  is  required  for  decryption.  In  the  worst  case,  it  takes  just  over  1.2 
seconds  to  decrypt  a  policy  with  17  topic  tags.  However,  since  99%  of  messages  have  five 
topics  or  less,  most  messages  can  be  decrypted  in  around  500  milliseconds. 


From  the  server  perspective,  the  biggest  impact  on  performance  is  the  size  of  the 
payload.  A  Twitter  message  represents  a  type  of  worst  case  in  terms  of  MA-AHASBE 
overhead.  First,  the  access  policy  is  potentially  different  for  each  message  and  so  it  must  be 
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Figure  5.11:  The  amount  of  time  to  encrypt  a  tweet  for  a  given  number  of  topics  and  the 
percentiles  of  mentions. 


included.  Second,  since  the  size  of  the  plaintext  message  is  so  small,  the  relative  overhead 
of  MA-AHASBE  is  significant.  The  ciphertext  sizes  are  shown  in  Figure  5.13.  Again, 
for  99%  of  messages  the  ciphertext  size  is  under  3,500  bytes,  but  can  be  as  large  as  5,200 
bytes  in  the  worst  case.  To  see  the  effect  on  server  performance,  several  client  machines 
are  used  to  saturate  the  system  by  sending  as  many  messages  of  a  fixed  size  as  possible 
in  a  60  second  window.  Figure  5.14  shows  the  effects  of  increasing  the  number  of  servers 
as  well  as  increasing  the  size  of  the  payload.  Each  box  plot  is  the  result  of  five  samples. 
As  expected,  increasing  the  number  of  servers  increases  the  throughput  while  increasing 
payload  size  decreases  throughput.  Based  on  the  data  from  Eigure  5.13,  we  see  that  most 
messages  will  fall  under  3,500  bytes.  While  this  has  a  modest  impact  on  performance. 
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Decryption  Time  per  Tag 


Figure  5.12:  The  amount  of  time  to  decrypt  a  tweet  for  a  given  number  of  topics  and  the 
percentiles  of  mentions. 


we  believe  there  are  situations  where  the  security  capabilities  of  a  system  such  as  Critter 
outweigh  the  performance  impact. 

5.6  Conclusions  and  Future  Work 

In  this  chapter,  we  have  proposed  a  security  model  that  reduces  the  trust  required  in  a 
CSP  to  availability  operations.  To  make  development  of  applications  easier  in  this  restricted 
model,  we  developed  a  framework  called  Axon  that  uses  a  small  set  of  data  structures: 
maps,  queues,  topics.  Axon  uses  the  cloud  to  provided  availability  and  durability  for  these 
data  structures.  On  the  client,  additional  secure  data  structures  and  protocols  are  created 
using  a  layered  approach.  Finally,  a  secure  messaging  application  Critter  was  built  using 
the  Axon  framework. 
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Ciphertext  Size  per  Topic 


Figure  5.13:  The  size  of  ciphertext  for  a  given  number  of  topics  and  the  percentiles  of 
mentions. 


An  aspect  of  dependability  that  isn’t  currently  addressed  by  the  Axon  framework 
is  being  able  to  function  even  when  the  connection  to  the  CSP  is  temporarily  lost. 
One  way  to  improve  this  aspect  of  dependability  in  this  area  is  to  cache  as  much  data 
locally  on  the  clients  as  possible.  This  benefits  performance  in  many  ways.  First,  if  the 
connection  to  the  CSP  is  lost,  access  to  at  least  a  portion  of  the  relevant  data  may  still 
be  accessible.  Meaningful  computations  may  still  be  accomplished  while  the  connection 
is  down.  Secondly,  caching  data  on  the  client  increases  the  availability  of  the  data  if  the 
cloud  version  becomes  corrupted.  Finally,  there  is  a  performance  advantage  as  the  data  is 
quicker  to  access  since  the  client  does  not  need  to  make  costly  network  calls  to  the  cloud 
in  order  to  access  the  data  it  needs.  An  important  negative  consequence  of  this  approach  is 
it  increases  the  storage  burden  on  the  client.  However,  many  client  machines  are  desktops 
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Figure  5.14:  Throughput  Performance  per  Number  of  Servers  and  Payload  Size.  The 
dashed  lines  represent  the  sample  mean  and  the  solid  line  indicates  the  median.  The  S 
label  indicates  the  number  of  servers  and  the  P  label  indicates  the  payload  size.  Pl=140 
bytes,  P2=3,500  bytes,  P3=5,000  bytes. 


where  local  storage  is  cheap.  Even  mobile  clients  can  have  significant  amounts  of  locally 
available  storage.  For  mobile  clients,  calls  to  local  storage  will  also  typically  be  more 
power  efficient  than  requests  that  must  go  over  the  network.  One  approach  would  be  to 
incorporate  conflict-free  replicated  data  types  (CDRT  [34])  within  Axon. 

Another  improvement  we  wish  to  make  is  to  model  the  protocols  in  Axon  using 
a  formal  modeling  language  such  as  SPIN  [57]  or  TLA-l-[68].  For  small  applications 
like  Critter,  a  formal  model  may  not  be  necessary.  However,  as  applications  increase  in 
size  and  complexity,  a  formal  model  can  help  ensure  that  all  data  is  processed  through  a 
security  mechanism  (such  as  a  secure  data  structure  or  protocol)  before  being  sent  to  a  core, 
unprotected  data  structure. 
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Finally,  we  would  like  to  extend  the  Axon  prototype  to  include  different  cloud 
implementation  designs  as  well  as  to  build  a  testing  suite  in  order  to  evaluate  the 
performance  of  each  implementation.  The  current  design  relies  on  ffazelcast,  but  we  would 
like  to  use  some  of  the  other  popular  messaging  frameworks.  Since  the  client  side  portion 
of  Axon  is  insulated  from  the  actual  cloud  side  implementation,  the  same  application  code 
could  be  used  for  each  cloud  implementation. 


118 


VI.  Summary  of  Contributions  and  Further  Research 


This  chapter  concludes  this  document  by  presenting  the  contributions  of  this  research 
as  well  as  providing  some  thoughts  on  the  direction  of  future  work.  The  cornerstone 
contribution  of  this  research  is  the  encryption  scheme  MA-AHASBE.  Building  on  this 
cornerstone,  the  other  contribution  of  this  research  is  the  demonstration  of  how  MA- 
AHASBE  can  be  used  to  build  applications  that  can  leverage  public  cloud  computing 
resources.  Euture  research  efforts  can  build  on  this  framework,  expanding  the  types  of 
services  that  can  be  provided  and  improving  the  computational  cost  for  doing  so. 

6.1  Contributions 

The  first  significant  contribution  of  this  research  is  the  development  and  implemen¬ 
tation  of  MA-AHASBE.  The  MA-AHASBE  system  presents  several  significant  develop¬ 
ments  in  attribute-based  encryption  research.  There  are  many  ABE  systems  that  individ¬ 
ually  have  each  of  the  characteristics  available  with  MA-AHASBE.  However,  to  the  best 
of  my  knowledge,  MA-AHASBE  is  the  only  system  that  incorporates  all  of  these  in  a 
single  system.  Attribute- sets  have  been  shown  to  be  a  useful  and  practical  extension  of 
ABE  [17].  MA-AHASBE  is  the  only  known  multi-authority  extension  of  ASBE.  In  fact, 
the  only  known  published  work  to  extend  ASBE  is  the  HASBE  system  which  provides  a 
type  of  hierarchical  extension.  The  hierarchical  mechanism  in  HASBE  does  not  provide 
for  hierarchical  autonomy,  which  as  argued  in  Chapter  4  is  a  requirement  for  an  efficient 
implementation  of  ABAC  with  an  ABE.  Aside  from  the  theoretical  contributions  of  MA- 
AHASBE,  the  implementation  of  MA-AHASBE  (described  in  Appendix  B)  stands  on  its 
own  as  a  novel  contribution.  The  implementation  shows  that  implementing  MA-AHASBE 
can  be  efficient  and  provides  insight  into  the  cost  of  policy  size,  number  of  users  in  the 
system,  and  the  penalty  involved  with  protecting  attributes. 
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The  second  significant  contribution  of  this  research  is  the  application  of  MA- 
AHASBE  to  the  area  of  microblogging.  Applying  MA-AHASBE  in  this  way  brought 
about  other  contributions.  Two  new  security  models  were  developed,  A-trusted  and  ACE- 
trusted,  with  ACE-trusted  being  the  model  most  applicable  to  public  cloud  computing. 
These  models  focus  on  availability  as  the  key  trust  requirement  between  a  client  and 
a  cloud  service  provider.  The  availability  requirements  are  defined  in  detail  through 
the  E-SCRAWE  operations,  a  novel  formulation.  The  A-trusted  model  only  has  the 
availability  trust,  while  the  ACE-trusted  model  adds  certain  computability  and  access 
control  enforcement  requirements.  While  this  does  increase  the  trust  required  in  a  CSP, 
the  efficiency  gains  can  be  significant  and  the  tradeolf  in  security  seems  reasonable  for 
reputable  CSPs.  Neither  model  requires  confidentiality  trust,  so  CSPs  cannot  learn  the 
contents  of  data.  In  order  to  support  this  model,  the  Axon  framework  is  presented. 
This  framework  demonstrates  a  layered,  data  structure  oriented  approach  to  building 
complex,  secure  data  structures  and  protocols.  This  method  is  used  to  build  Critter,  a 
secure  microblogging  application.  Performance  results  indicate  that  while  there  is  a  cost 
associated  with  enforcing  an  ACE-trusted  model  in  Critter  versus  processing  the  data  in 
plaintext,  the  cost  is  not  unreasonable  and  the  benefits  in  security  can  be  significant.  This 
is  particularly  important  if  the  messages  being  shared  in  Critter  are  sensitive  or  require 
complex  access  control  policies. 

6.2  Future  Work 

This  work  will  hopefully  new  doors  and  new  ways  of  thinking  about  how  cloud 
services  can  be  secured.  Already  there  are  some  tangential  elforts  at  AEIT  that  build 
on  the  work  presented  in  this  research.  One  effort  is  looking  at  techniques  to  speed  up 
pairing  computations  using  graphics  hardware.  Research  already  exists  that  accomplishes 
this  with  composite  order  groups  [110],  but  in  order  to  work  with  MA-AHASBE  the 
techniques  would  need  to  be  adopted  for  prime  order  groups  and  Type-3  pairings.  If 
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successful,  this  could  improve  the  effieieney  and  seale  of  a  MA-AHASBE  implementation. 
Also,  similar  teehniques  used  in  MA-AHASBE  for  eombining  ASBE  and  AHIBE  eould 
be  used  with  the  system  deseribed  in  [90]  whieh  uses  only  standard  assumptions,  instead 
of  the  non-standard  assumptions  used  in  MA-AHASBE.  This  extra  boost  in  seeurity 
eonfidenee  eomes  at  a  potentially  signifieant  eomputational  eost.  This  is  beeause  what 
where  single  term  multiplieations  in  MA-AHASBE,  now  beeome  veetor  multiplieations 
in  [90].  The  eapability  to  speed  up  pairing  eomputations  using  graphies  hardware  eould 
help  mitigate  this  extra  eomputational  eost.  Cloud  resourees  that  inelude  very  powerful 
graphies  hardware  are  beeoming  more  eommonplaee  from  their  use  in  seientifie  eomputing 
applieations.  So  the  improvement  of  pairing  eomputations  using  graphies  hardware  fits 
seamlessly  in  the  seeure  eloud  eomputing  paradigm. 

Another  interesting  applieation  of  this  approaeh  is  in  software  version  eontrol.  Current 
researeh  at  AEIT  is  looking  at  ways  to  seeure  the  popular  version  eontrol  software  git. 
Similar  to  the  applieation  in  Chapter  5,  this  approaeh  would  mesh  well  with  MA-AHASBE. 
Speeifieally,  MA-AHASBE  eould  be  used  to  provide  fine-grained  attribute  based  eontrol  to 
partieular  files  or  folders  for  both  read  and  write  aeeess.  Also,  it  is  possible  that  the  eoneepts 
used  in  seeuring  git  eould  be  extended  and  applied  to  a  fully  version  eontrolled,  seeure  file 
system.  Einally,  MA-AHASBE  ean  be  used  with  many  eryptographie  systems  whieh  are 
based  on  symmetrie  keys  sueh  as  enerypted  seareh  and  group  eollaboration  (additional 
notes  on  these  applieation  areas  are  provided  in  Appendix  C). 

6.3  Conclusion 

The  end  result  of  the  eontributions  presented  in  this  researeh  is  to  support  the  thesis 
statement  stated  in  Chapter  1 : 

Efficient  techniques  exist  to  support  the  secure  use  of  public  cloud  computing 

resources  by  a  large,  federated  enterprise. 
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MA-AHASBE  combines  with  a  hybrid  cloud  computing  model  where  the  public  cloud 
service  providers  operated  under  an  ACE-trusted  model  of  security.  This  forms  the 
backbone  of  key  management  that  is  designed  to  support  an  ABAC  paradigm  in  a  large, 
federated  enterprise.  The  application  focused  contributions  support  the  claim  that  this 
approach  can  be  successfully  applied  to  tasks  such  as  microblogging.  The  future  work 
highlights  areas  where  additional  services  such  as  search,  real-time  collaboration  and 
version  control  can  be  added.  It  also  may  be  possible  to  improve  the  efficiency  of  the 
current  approach  through  the  use  of  graphics  hardware.  Overall,  the  results  of  this  type 
of  research  will  hopefully  contribute  to  a  new  approach  to  securing  sensitive  information 
while  being  able  to  take  advantage  of  the  ever  decreasing  costs  of  cloud  computing. 
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Appendix  A:  MA-AHASBE  Security  Proof  Details 


A.l  Notation  and  Preliminaries 

This  proof  describes  group  operations  assuming  they  are  written  multiplicatively,  even 
though  we  write  some  groups  such  as  Gi  additively.  The  concepts  apply  regardless  of 
the  notation  for  the  groups.  For  example,  the  variable  s  in  the  term  sPi  is  referred  to  as 
being  “in  the  exponent”  of  Pi.  The  proof  demonstrates  security  under  chosen  plaintext 
attack  or  CPA.  The  CPA  construction  is  made  by  reversing  the  CCA  transform  used  in  the 
construction  given  in  §4.4  by  applying  the  following  changes: 

•  Remove  CTcom  and  CTtag  from  the  ciphertext  CT 

•  Remove  Co-  from  CT 

•  Replace  k'  in  the  global  leaf  nodes  with  the  message  m  6 

This  modified  encryption  algorithm  is  referred  to  as  EncryptQp/^.  Since  CT  com  and  CTtag 
are  no  longer  in  the  ciphertext,  there  is  no  need  to  perform  the  checks  to  make  sure  they 
are  consistent.  Also,  the  new  message  recovery  algorithm  for  m  becomes  the  old  recovery 
algorithm  for  k' .  Ciphertexts  created  using  EncryptQp^  are  labeled  CTcp^.  For  this  proof, 
the  ciphertexts  do  not  include  the  plaintext  policies  as  this  would  make  it  trivial  for  the 
adversary  to  distinguish  the  message-policy  pairs.  The  adversary  has  access  to  the  policies 
since  they  are  included  in  the  adversary’s  submission,  they  are  just  not  returned  in  the 
encryption. 

For  ease  of  presentation,  the  instantations  below  show  the  simulator  choosing  the 
global  parameters.  In  particular,  the  simulator  knows  the  global  secret  key  GS  K.  This 
allows  the  simulator  to  execute  the  user  key  generation  algorithm  that  requires  the  user 
identifier  requested  by  the  adversary.  However,  this  also  allows  the  simulator  to  facilitate 
collusion  as  described  in  §4. 5. 2. 3,  since  it  is  in  effect  acting  as  the  trusted  central  authority. 
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In  order  to  achieve  the  security  required  by  the  security  game  in  §4.5.1,  the  simulator 
cannot  know  these  values.  This  can  be  achieved  using  a  secure  computation  protocol, 
and  the  method  chosen  affects  the  overall  set  of  security  assumptions.  The  simulator 
and  adversary  can  participate  in  a  two-party  secure  computation  protocol  (as  described 
in  §4.3.2. 1)  to  compute  the  values  according  to  the  algorithms  in  global  setup.  Note  that 
this  can  be  done  adaptively  as  the  adversary  is  requesting  keys.  In  this  approach,  neither 
the  simulator  nor  the  adversary  know  the  components  of  GSK,  but  merely  have  access 
to  the  global  parameters  which  includes  the  user  identifier  parameters.  However,  any 
cryptographic  assumptions  made  by  the  two-party  secure  computation  protocol  (for  which 
there  are  standard  model  schemes  such  as  [23])  must  be  added  to  the  assumptions  presented 
in  §4.5.3. 

Each  lemma  presented  here  follows  the  same  pattern.  First  the  cryptographic 
assumption  is  presented.  Then  the  simulator  instantiates  the  global  and  local  authority 
parameters  using  the  terms  in  the  assumption.  The  setup  is  followed  by  the  key  extraction 
phases.  Since  there  is  no  computational  difference  between  Phase  1  and  Phase  2  as 
described  in  MA-AHASBE  security  game,  these  phases  are  presented  together.  Also,  the 
computations  are  only  shown  for  domain  key  extractions  and  not  for  user  key  extractions. 
The  adversary  may  request  a  key  of  either  type.  If  the  adversary  requests  a  domain  key, 
the  simulator  follows  the  procedures  described  in  the  proof  and  returns  the  result.  If  the 
adversary  requests  a  user  key,  the  simulator  first  creates  the  corresponding  domain  key 
using  the  proof  procedure,  and  then  uses  the  unmodified  algorithm  UserKeyGeneration  to 
create  the  user  key.  Recall  that  a  user  key  inherits  the  semi-functional  properties  (normal, 
full,  partial)  of  the  domain  key  that  creates  it.  The  unique  portion  of  either  type  of  key 
extraction  query  is  the  domain  key  generation  and  so  that  is  all  that  is  presented. 

Next,  the  adversary  submits  two  message-policy  pairs  for  the  challenge  phase.  Recall 
that  the  two  policies  must  be  structurally  equivalent.  In  MA-AHASBE,  the  q  terms  in  the 
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ciphertext  represent  the  splitting  of  the  seeret  5  aeeording  to  the  poliey.  Sinee  5  is  not 
typieally  direetly  available  to  the  simulator,  the  eomputation  for  eaeh  q  term  must  now  be 
done  in  the  exponent.  The  terms  in  the  polynomial  ean  be  represented  by  (where 
g  is  a  generator  and  is  the  randomly  ehosen  eoeffieient)  with  the  addition  of  terms  by 

2  3  2  3 

gOix  _  gao+aix+a2x  +fl3x  ...  generator  g  and  the  initial  term  g*  are  given, 

then  the  remainder  of  the  terms  ean  be  ealeulated  using  the  same  method  deseribed  in 
the  EncryptQpy^  algorithm  in  the  exponent  rather  than  direetly.  Therefore,  in  the  proofs  we 
give  the  eomputations  for  the  initial  values  eontaining  g\  The  eomputation  for  the  relevant 
generator  g  is  nearly  identieal  to  what  is  shown  for  g^  only  dropping  the  s  in  eaeh  term 
where  it  appears.  In  eaeh  lemma,  the  relevant  terms  without  s  values  are  present  in  the 
assumption.  The  simulator  ean  then  ealeulate  the  relevant  values  aeeording  to  the 
poliey.  The  result  remains  in  the  exponent  sinee  this  is  what  the  eiphertext  requires  and 
sinee  the  simulator  eannot  eompute  the  ^„(0)  values  direetly. 

In  eaeh  eomputational  seetion,  the  aetions  of  the  simulator  are  presented  in  the  same 
order.  First  the  simulator  ehooses  some  set  of  parameters  randomly.  The  simulator  then 
explieitly  sets  some  set  of  parameters.  These  are  the  parameters  that  the  simulator  ean 
explieitly  eompute  and  usually  represent  eomponents  that  will  be  returned  to  the  adversary. 
Beeause  of  the  explieit  eomputations,  some  parameters  are  implieitly  set.  Usually  the 
simulator  eannot  direetly  eompute  these  parameters,  but  they  are  useful  in  understanding 
the  limitations  of  the  simulator  for  the  given  lemma.  Finally,  eaeh  lemma  eoneludes  with 
the  adversary  submitting  a  guess  for  whieh  message-poliey  was  ehosen.  A  short  deseription 
is  then  given  that  explains  how  this  guess  eorresponds  to  the  seeurity  games  presented  in 
Seetion  5.  Note  that  at  any  time  during  the  key  extraetion  phases,  the  simulator  traeks 
the  requests  and  ean  determine  if  the  adversary  has  requested  keys  that  allow  for  a  trivial 
deeryption.  If  this  is  the  ease,  the  simulator  aborts.  The  simulator  ean  also  deteet  if  the 
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policies  submitted  for  the  challenge  are  not  structurally  equivalent  and  also  aborts  in  this 
case. 

The  following  shorthand  will  be  used  throughout  the  proofs  where  id  represents  a 
domain,  attr  represents  an  attribute,  and  y,  y,  Aij,  v,  represent  parameters  chosen  by  the 
simulator  during  the  proof: 

id  =  <idi,...,id^) 

attr  =  <attri,...,attr^) 

e 

hi(id)  =  2  yij\dj  +  Ui 
i=\ 

t 

=  Z  +  Vi 

,/=i 

A.2  Lemma  4.1. 

\Pv\Xreal\  ~  ^  ^LWl 

A.2.1  Assumption. 

LW 1  =  (Fi ,  bsFi ,  sFi ,  aFi ,  ab^F\ ,  bFi ,  b^Fi ,  asFi ,  b^sFi ,  b^Fi ,  b^sFi ,  F2,  bF2,  Zi) 

Let  Zi  =  {ab^s  +  y)Fi.  It  is  hard  to  decide  whether  7  =  0  (Zj  is  real)  or  7  £u  Zp  (Zj  is 
random). 

A.2.2  Setup(A,  Uauth)- 

SS  receives  an  instance  of  LW  1  and  chooses: 

p,  e,  "FI,  h  based  on  A 

t  ^ 

(Vg,fiid,  {P j} je[Q,r„axhy ■'  L'};£[l,na„,A]  ^ 

irf  ^  ^2 

^  explicitly  sets  Vz  e  [1, 

Pi  =  b^Fi  +  7F1 

a;Pi  =  kiHah^Fi)  +y{aFi)) 

TiPi  =  Oiib^Fi)  +  kiv'-iab^Fi)  +  Oiy(bFi)  +  kiv'-y(aFi) 
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QiXj  = 

ciiQixj  =  {ki{hjo]{ab'^Fi)+yi^j{aFi))]je[\XnaA 

TiQi,i,j  =  {Aijo]{b^Fi)  +  kiv[Aijo^iab^Fi)  +  Oiyij(bFi)  +  kiv'.yij(aFi))}jexh^^^] 

Ui,i  =  ViO^ib^Fi)  +  UiFi 

aiUi^i  =  kiiviO^iab^Fi)  +  Ui(aFi)) 

T,t/,- 1  =  OiVio]{b^Fi)  +  kiV'.Viojiab^Fi)  +  OiUi(bFi)  +  kiV\Ui{aFi) 

Vi2  =  Oi{bF2) 

^2  =  ^iF2 

e{Pi,Pu2r  =  (e(o^(b^F,)  +  b^F,  +  yF^,yF2)e(o^(b^F^),bF2)r 

GSK: 

^  implicitly  sets  V/  6  [l,nauth]' 

Ui  =  kiU 
Vi  =  bi  =  Oib 

Ti  =  Oib  +  kiav\  =  bi  +  a,V;  =  v,-  +  a,v' 

Pi,2  =  ib]xy)F2 

QiXj  =  {hjO^ib'^F  2)  +  yijF  2}jeU,h„a.] 

Ui2  =  Vioj(b^F2)  +  UiF2 


SS  publishes  for  all  players  including  : 

GP:  {p^e.Pi,KPuF2.PidPu  ^^2, 

APi.  {QiP  \,TiP  G  i\^  UiU  ii^TiU  i\^  ^^2)  * 


A.2.3  Phases  1  and  2. 

sF  makes  q  key  extract  queries.  FS  does  not  know  {Pi^,  QiXj,  t//,2};6[i,n,„A];;£[i,/i„„,]  which  are 
the  master  secrets  for  each  authority. 
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SS  receives  a  key  query  for  a  domain  with  id  =  (idi, id^)  under  authority  i  where 

i  e  [l,nauth]  and  chooses: 

r' , r', r', (z[  j, ^  ^*p 


SS  explicitly  sets  Vj  6  {€  + 

^1,1  =  WiyF2  +  r\oi{bF2) 

Ki,2  = 

^1,3  =  ^1^2  -  WiOi{bF2) 

^2,1  =  0'iyF2  +  r'^Oi{bF2)  +  Wi/z,(id)F2 
^2,2  =  V-^2,3 

^2,3  =  ^2^2  -  o;(wi^,(id)  +  ai)(bF2) 

Dpi  =  wiyijF2  +  z[jOi(bF2) 

Dp2  =  v'Pp3 

=  z'ijF2  -  WiAijOi(bF2) 

7j  1  =  w2yF2  +  r'^Oi(bF2) 

J\,l  = 

■/l,3  =  ^3^2  -  W20i{bF2) 

hi  =  rhiibF2)  +  W2hi(id)F2 

h,l  =  V-72,3 

■/2,3  =  ^4^2  -  W20igi{\d){bF2) 

Epi  =  W2yi,jF2  +  Z2jOi{bF2) 

Ej,2  =  v'lhs 

^73  =  ~  W2hjOi(bF2) 


128 


SS  implicitly  sets: 

n  =  r\  -  wiOib 

r2  =  r'^-  Oib(wigi(id)  +  a,) 

rj  =  r'  -  W20ib 

r4  =  -  W2giOib(id) 

~  '^ihjOib 
Z2,j  =  Z2J  -  W2AijOib 

If  the  request  was  for  a  domain  key,  ^  returns  the  components  computed  above  to  s?/ 
as  the  domain  key.  Otherwise  ^  computes  the  user  key  according  to  the  algorithm 
UserKeyGeneration  and  returns  the  result  to  £/  as  the  user  key. 

A.2.4  Challenge. 

receives  two  message-policy  pairs  (Mq,  Pq)  and  {Mi,P\). 

^  chooses: 
yS*4^{0,l} 

explicitly  sets  (where  attrc  ranges  over  each  leaf  node  attribute  in  the  policy): 
spdPi  =/3d(b^sFi  +y(sFi)) 

e(PuPi,2y‘^-  =  (e(o^(bhFi)  +  bhF,  +  y(sF,),yF2)e(o^(b^sFi),bF2)r 
e{Pi,F2y°‘^  =  eQj^sF^  +  yC^FO,  ^2)“* 

Ci,i  =  ^FfiCattrO  =  o]gi{eiiiry){b'^sFi)  +  hi{siiiry)isFi) 

Cl, 2  =  asFliieLiiYc)  +  ficrFi  =  ofk,g,(attrc)Zi  -1-  k,/z,(attrc)(a5Fi) 

Cl, 3  =  -r^FfiCattrO-yua-y;  =  -o]gi{2Liiry)ib^sFi)-oMsiiiry){bsFy)-kio]v[gii,2iiiry)Zi- 
kiv[hi{2iiirc){asFi) 

C2,i  =  sPi  =  b^sFi  -l-y(5Fi) 

C22  =  cisPi  +  [xFi  =  kiZi  +  yki{asFi) 
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C2,3  =  -TsPy  -  IIV[  =  -Oi{b^ sFi)  -  yOiibsF 0  -  kiV'.Zy  -  kiV'.(asFi) 


SS  implicitly  sets: 
yu  =  0  or  random 
a  =  ^,(attrc) 

^  encrypts  Mp*  under  the  policy  P*^,  using  the  values  above  and  the  algorithm  EncryptcpA 
and  returns  the  result  C7“cpa-  Note  that  if  Z\  =  ab^sFi  then  the  ciphertext  is  normal. 
Otherwise,  Zi  =  {ab^s+ix)Fi  for  some  n  &u  '^p  and  the  ciphertext  contains  semi-functional 
leaf  nodes  with  /r  =  /r  and  cr  =  g;(attrc).  Finally,  note  that  since  cannot  compute  aF2,  ^ 
cannot  compute  a  semi-functional  key  in  order  to  determine  if  CT zpa  is  semi-functional. 
A.2.5  Guess. 

£/  returns  its  guess  /3'  to  ^ 

If  Zi  is  real,  CT cpa  is  normal  and  therefore  is  simulating  Gamereai-  Otherwise,  Zj  is 
random  and  CT  cpa  is  semi-functional  and  therefore  FS  is  simulating  Gameo.  If  returns 
1  if  /3*  =  yS'  and  0  otherwise,  then  it  can  solve  the  LW 1  problem  with  advantage: 


Adv;^'^^  =  \Pr[J3*  =  yS'lZi  is  real]  -  Pr[j3*  =  /3'\Zi  is  random]]  =  |Fr[A,,«/]  -  Fr[Ao]| 

A.3  Lemma  4.2. 

\Pr[Xk-ij]  -  Pr[Xkfi]\  <  etwi  for  1  <  k  <  ^ 

A.3.1  Assumption. 

LW2  =  (Fi,dFi,d^Fi,bxFi,dbxFi,d^xFi,  F2,dF2,bF2,cF2,Z2) 

Let  Z2  =  (be  +  y)F2.  It  is  hard  to  decide  whether  7  =  0  (Z2  is  real)  or  7  6j/  Zp  (Z2  is 
random). 
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A, 3, 2  S€tlip(A^  ^auth)* 

SS  receives  an  instance  of  LW2  and  chooses: 
p,  e,  "K,  h  based  on  X 

{13  j]  ie[Q,r„ax]^  {^i’  {jij’’  M,-, 

Qid,  U id  <—  G2 

^  explicitly  sets  V/  6  [!,««„(/,]: 

Pi  =  dFi 

aiPi  =  aiidFi) 

TiPi  =  d^Fi  +y^^i{dFi) 

QiXj  =  {3i,j(dF  1)  +yi,jF  i]je[\,h„,A 

~  {(^ii3i  j{dFl^  js[l,hmax] 

TiQixj  =  [Xijid'^Fi)  +  XQyyd(dFi)+yi^j{dFi)Xyi^jyydF\]M\,h„ax] 

Ui^i  =  ViidFi)  +  UiFi 
aiUi^i  =  ai{vi{dFi)  +  UiFi) 

TiUi^i  =  Viid^Fi)  +  Viy^didFi)  +  UiidFi)  +  M;yv,,Fi 

Via  =  -aiOiibF2)  +  dF2  +  y^^Fi 
y'2  =  Oi{bF2) 

Pi,2  =  ki(dF2) 

QiXj  =  {3i,j(dF  2)  +  yijF  2}je[\,h„ax^ 

Via  =  Vi(dF2)  +  UiF2 

e{Pi,Piar  =  e{dFiMdF2)r 
GSK:  {j-,r-^,l,Qid,Uid) 

implicitly  sets  Vi  G  \X,nauth\'- 

bi  =  Oib 
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Vi  =  -Uibi  +  d  +  y^j  =  -ttiOib  +  d  + 
v'i  =  bi  =  Oib 
Ti  =  d  +  y^j 


SS  publishes  for  all  players  including  : 

GP-.  {p,e,P{,h,PuF2,liidPi,  ^F2,{;0,Pi,^F2},e[o,._],e(Pi,F2rO 

APi-  [ciiPi,  TiPi,  U i  \,  Q-iU i  \,TiU i  \,  {Qi^lJ,CliQi^lJ,TiQi  i  j}j£[i  h^^],6(^Pi,Pi  2)  ‘]ie[l,nauth] 


A.3.3  Phases  1  and  2. 

makes  q  key  extract  queries  labeled  qe  where  06  [1,^].  If0<ka  semi-functional  key 
is  returned  and  if  0  >  k  a  normal  key  is  returned.  creates  semi-functional  keys  using  the 
master  secret,  a,  and  F2.  From  Z2,  if  y  =  0  then  the  key  is  normal,  otherwise  if  y  &u 
then  the  key  is  partially  semi-functional  with  yi  =  y,n  =  giisMYc^k)  and  nij  =  3ij. 


SS  chooses: 


For  6  =  k,  FS  computes  Si'i  j  &{£  +  1,0']: 

Kij  =  w\P2  -  aiZ2  +  yv,i(cF2) 

K,,2  =  Z2 
Kiy,  =  CF2 

K2,\  =  aiP2+w\{gi(,2inYc,k)idF2)  +  hi{nnYc,k)F2)  +  F2^2-aigi(,2inYc,k)Z2  -tyv,,gr(attrcy)(cF2)- 
0;(attrc,yt)(cF2) 

^2,2  =  ^2^2  +  .?((attrc,^)Z2 
^2,3  =  r'^F2  +  g;(attrcy)(cF2) 

F>j,i  =  w'l  22,2  +  z'l jF2  -  yij(cF2)  -  aiAijZ2  -h  yv,ihj{cF2) 

Dj.2  =  z[jV'  +  AijZ2 
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~  +  ^UjicFl) 


SS  computes  S2  normally. 

SS  implicitly  sets  Vj  e  [^  +  1,  /z']: 

Wi  =  w[  -  c 
ri  =  c 

r2  =  r'^  +  gii^iirc,k)c 

A.3.4  Challenge. 

receives  two  message  policy  pairs  (Mq,  P*q)  and  {Mi,P\). 

^  chooses: 

>S*^{0,1} 

^  explicitly  sets  (where  attr^  ranges  over  each  leaf  node  attribute  in  the  policy): 
sPdPi  =l3d{dbxFi) 

eiPuPigy^'  =  e{dbxFukidF2r 
e(Pi,F2)“*  =  e{dbxFuF2y^ 

Ci,i  =  sFliiattVc)  =  g;(attrc)(J(?.rFi)  + /z,(attrc)((?.rFi) 

Ci_2  =  asFtiiattVc)  +  iicrFi  =  a,g;(attrc)(J(?.rFi)  +  a;/z;(attrc)((?.rFi)  -  g,(attrc)(J^.rFi) 
Ci,3  =  -TsF{\{siiirc)-ixcrV[  =  -yv,igi{^^krc){dbxFi)-hi{siiirc){dbxFi)-yvd^i{siiirc){bxF\) 
€2,1  =  sPi  =  dbxFi 

C22  =  asPi  +  fxFi  =  UiidbxFi)  -  d^xFi 
C2,3  =  -rsPi  -nV[  =  -y^didbxFi) 
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SS  implicitly  sets: 
s  -bx 
Id  =  -d^x 
a  =  ^,(attrc) 

dS  encrypts  Mg.  under  the  policy  using  the  values  above  and  the  algorithm  EncryptQp^ 
and  returns  the  result  CT cpa- 
A.3.5  Guess. 

£/  returns  its  guess  /?'  to 

If  Z2  is  real,  is  simulating  Otherwise,  Z2  is  random  and  dd  is  simulating 

Gamekfl-  If  returns  1  if  jS*  =  /?'  and  0  otherwise,  then  it  can  solve  the  LW2  problem  with 
advantage: 


Adv^”'"  =  \Pr[J3*  =  /3'\Z2  is  real]  -  Pr[J3*  =  0\Z2  is  random]]  =  \Pr[Xt-i,i]  -  Pr[Xtfl]\ 

A.4  Lemma  4.3. 

\Pr[Xk^o]  -  Pr[Xk,i]\  <  6lw2  for  1  <  ^ 

This  is  the  same  procedure  as  Lemma  2  except  that  S2  is  used  rather  than  ^Si.  This  is 
easily  done  since  the  only  difference  between  and  S2  is  that  the  latter  does  not  include 
a,/’2-  Since  Q',/’2  is  explicity  calculated,  it  is  straightfoward  to  remove.  Si  is  made  semi¬ 
functional  for  every  key  extraction  query. 

A.5  Lemma  4.4. 

\P^\Xq,\\  —  P^lXm-randornW  ^  ^DBDH-3 
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A.5.1  Assumption. 

DBDH-3  =  {Fi,aFi,bFi,  sFi,F2,aF2,bF2,  sF2,Zt) 

Let  Zt  =  e{F i,  F2y^^^^ ■  It  is  hard  to  decide  whether  y  =  0  {Zj  is  real)  or  y  Gy  {Zj  is 
random). 

A. 5.2  Sctup( 

SS  receives  an  instance  of  DBDH-3  and  chooses: 
p,  e,  F(,  h  based  on  X 

[1^  j)  ie[Q,r„u,x\^y  ^  {j  i,j)  ie[\,h^^]^Ui]ie[l,nauth\  ^ 

Qid,  U id  <—  G2 

explicitly  sets  V/  6  \l,nauth\'- 

Pi  =  yFi 

UiPi  =  ykiiaFi) 

TiPi  =  v;y(Fi)  -I-  kiv\y{aFi) 

Qi,\,j  =  {yi,jP\]je[\,hmaA  =  {yi,iyiP\)]je[\.h„ax^ 
atQixj  =  {yi,jykiiaFi)}j^xh„,.^] 

TiQixj  =  {viyujyiFi)  +  kiv'iyijy(aFi)}jexh„,A 

Uij  =  UiPi  =  UiyiFi) 

Uilli^i  =  kiUiyiaFi) 

TiUi,i  =  ViUiy(Fi)  +  kiv\uiy{aFi) 

Vi,!  =  ViF2 

yi2  =  v:^2 


Pi,2  =  kiy(F2) 

Qixj  =  {yi,jy(F2)}jeu,h„a.] 
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Ui2  =  Uiy(F2) 


eiPuPi^r  =  e{aFubF2p" 
GSK: 

^  implicitly  sets  V/  6  [l,nauth]'- 
a,  =  kiU 
ai  =  ttib 
Ti  =  Vi  +  aiv\ 


^  publishes  for  all  players  including  sF  : 

GP-.  {p,e,F{,h,PuF2,fiidPu  ^F2,{;0,Pi,^F2},.e[o,._],e(Pi,F2rO 

APi .  { CliP\ ,  TiP\ ,  Uj  i,  CliUi  i,  T;  t/(  1 ,  { Qi^lj,  ie[\,h„ax\ ’  ^(^1  ’  Pi.l)  ‘}ie[l,nauth] 


A.5.3  Phases  1  and  2. 

makes  a  number  of  key  extract  queries.  Note  that  SS  does  not  know  a,  or  q',F2  and 
therefore  cannot  create  a  normal  key. 


SS  receives  a  key  query  for  a  domain  with  id  =  (idi, ...,  id^)  under  authority  i  where 
i  6  [l,nauth]  and  chooses: 

u 

r' ,  r',  r',  (z[  j,  i^j)^  r]j)je[M,h'pWuW2,  r'l,  Ti,  72,  H  ^  ^*p 


SS  explicitly  sets  Vj  e  {€  +  1,  h']: 

^1,1  =  WxPi2  +  riy,-2  -  yiki(aF2) 

^1,2  =  ^1^,;2  71^2 

^1,3  =  f  iFl 

K2,i  =  y\ki{aF2)  +  wi/z,(attr)/’,;2  +  /■2  V, -2 
^2,2  =  r2Vl^  +  y{bF2)  -  y[F2 
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^2,3  -  ^2^2 

Djj  =  wiQiXj  +  zi,jVi2  -  yinjki{aF2) 

Dj2  =  zijV'.2  +  ymjFi 

Dj,3  =  ZijF2 

Ji,i  =  W2Pi,2  +  r^Vi^  -  y2kiiaF2) 

J\,i  =  +  yiFi 

■^1,3  =  ^3^2 

J2,\  =  -y2ilki(aF2)  +  W2/z,(attr)P,;2  +  ?'4Vi,2 
J22  =  r4V.2  +  y2r]F2 
^2,3  =  ^aF2 

Ej,i  =  W2Qi,2j  +  Z2jVia  -  y2Vjki(aF2) 

Ej,2  =  Z2,jVl^  +  y2rijF2 

Ej,3  =  Z2jF2 

SS  implicitly  sets: 
aij'x  =  by -yin 

A.5.4  Challenge. 

receives  two  message  policy  pairs  (Mq,  P*q)  and  {Mi,P\). 

^  chooses: 

P*  ^{0,1}  yi' 

SS  explicitly  sets  (where  attr^  ranges  over  each  leaf  node  attribute  in  the  policy) 
s^dP\  =  t^dyisFi) 
eiPuPi^r'^^'y  = 
e{PuF2y"^  =  e{y{sFi),F2T^ 
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Ci,i  =  5'Ki(attrc)  =  yhi{&nYc){sFi) 

Ci,2  =  a5'Ki(attrc)  +  jJ-crFi  =  /z,(attrc)/i'Fi 

Cl, 3  =  -TsFiiisAiYc)  -  no-V[  =  -Viyhi(sinYc){sFi)  -  V;/z,(attrc)//'Fi 
C2,l  =  sPi  =  y(5Ci) 

C2,2  =  +  lJ.Fi  =  //'Fi 

C2,3  =  -TsPi  -ijV[  =  -yVi(sFi)  -  v'.jj'Fi 


SS  implicitly  sets: 
s  -  s 

IJ=  IJ'  -  aisy 
a  =  hi{siiiYc) 

^  encrypts  Mp*  under  the  policy  P*^,  using  the  values  above  and  the  algorithm  EncryptcpA 
and  returns  the  result  CT cpa- 
A.5.5  Guess. 

£/  returns  its  guess  /?'  to  ^ 

If  Zt  is  real,  ^  is  simulating  Gameq  i.  Otherwise,  Zj  is  random  and  ^  is  simulating 
Game  final-  If  ^  returns  I  ifyS*  =  [S'  and  0  otherwise,  then  it  can  solve  the  DBDH-3  problem 
with  advantage: 

Adv|^^^-3  =  \Pr\fi*  =  J3'\Zt  is  real]  -  Pr[J3*  =  J3'\Zt  is  random]|  =  |Fr[X,,i]  -  Pr[XM-random]\ 

A.6  Lemma  4.5. 

\Pf\Z-M— random]  P^\.Z final]]  —  ^Al 
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A.6.1  Assumption. 

A1  =  {Fi,zFi,dzFi,azFi,adzFi,  szFi,F2,zF2,aF2,xF2,{dz  -  ax)F2,Zd) 

Let  Zi  =  csdzFi.  It  is  hard  to  decide  whether  c  =  1  (Zi  is  real)  or  c  6j/  Zp  (Zi  is  random). 
A.6.2  Setup(A,nauth)- 
SS  receives  an  instance  of  A1  and  chooses: 
p,  e,  FI,  h  based  on  A 

(Xg,Pid,  [1^  j)  ie[0,r„ax]^  ^ 

Qid,  U id  <—  G2 

^  explicitly  sets  V/  6  \l,nauth\- 

Pi  =  zF, 

UiPi  =  kiiazFi) 

TiPi  =  ViizFi)  +  kiV'.{azFi) 

Qi,l,j  —  {yi,j(dzFl)}j^[l^h„ax] 

atQiXj  =  {kiyi,j(adzFi)]je[i,h^^^] 

TiQi,ij  =  {viyijidzFi)  +  kiv'.yij{adzFi)]j^[i^h,n,^i^ 

Uij  =  Ui(dzFi) 
aiUij  =  kiUi(adzFi) 

TiUi^i  =  Vi{dzFi)  +  kiv'i(adzFi) 

Via  =  ViF2 

y'l  = 

Pi,2  =  OiZF2 

e(PuPi,2y‘  =  e(zFuOi(zF2)T‘ 

GSK:  {j^,--^,l,Qid,Uid) 
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SS  implicitly  sets  V/  6  [l,nauth]'- 

Ui  =  kiU 
Zi  =  OiZ 
Ti  =  Vi  +  ttiV. 

QiXj  =  {yij(dzF2)}je[l,h„,a.] 

Ui,2  =  Ui{dzF2) 


SS  publishes  for  all  players  including  : 

GP-.  {p,e,Fi,h,PuF2,PidPl,  ~-^F2,{PjPl,^F2)je[0,r^^^},e{P,,F2T^) 

APi .  { CliP\ ,  TiP\ ,  Ui  i,  CliU i  \,  T;  t/(  1 ,  { Qi^lj,  "ZiQi  i  j} ie[\,h„ax\ ’  ^(^1  ’  Ft  2d  ‘}ie[l,nauth] 


A.6.3  Phases  1  and  2. 

makes  q  key  extract  queries. 


dS  receives  a  key  query  for  a  domain  with  id  =  (idi, id^)  under  authority  i  where 
i  E  [l,nauth]  and  chooses: 

r' ,  r2,  r',  (z[  j,  (nj),  qj)je[e+i,h'pWuW2,  n',  yi,  72,  v'  ^  Zp 


dS  explicitly  sets  Vj  G  {€  +  \,h'Y 
Ki,i  =  wiPi2  +  riy,-2  -  yikiiaF2) 

Ki2  =  ^1^,;2  TI'^2 

^1,3  = 

i^2,i  =  cniPi^  +  Wihi{siiiY){dz  -  ax)F2  +  r2y,-,2  -  y\kin'{aF2) 
K22  =  r2V.2  +  wi/z;(attr)(.rF2)  +  yin'F2 

^2,3  =  ^2^2 

F>j,i  =  Wiyijidz  -  ax)F2  +  ZiqVi^  -  yin'jki{aF2) 

Dj2  =  zi  jy-2  +  wiyijixF2)  +  yi:T'.F2 
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^;,3  -  Z  1,7^2 


^1,1  =  W2Pu2  +  r^Vi^  -  y2ki{aF2) 

J\,2  =  ^3 ^^2  72^2 

■^1,3  =  ^3^2 

72,1  =  W2hi{‘&iir){dz  -  ax)F2  +  r^Vi^  -  y2d'ki{aF2) 

J22  =  r4Vl2  +  W2hi(aUr)(xF2)  +  y2r]'F2 
72,3  =  ^4^2 

Ej,i  =  W2yi,j(dz  -  ax)F2  +  22,7 ^1,2  -  y2Jl'jkiiaF2) 

Ej,2  =  Z2,jVl2  +  wiyi,j(xE2)  +  y2d'jE2 

Ej,3  =  Z2,jE2 

SS  implicitly  sets: 

;7r  =  tt'  +  y'[^wihi{aiir)x 
TTj  =  n'j  +  r;'^Wiy;j3C 
rj  =  rj'  +  y2^W2hi(attr)x 
dj  =  d'j  +  y2^W2yi,jX 

A.6.4  Challenge. 

dd  receives  two  message  policy  pairs  (Mq,  Pq)  and  {Mi,P\). 

^  chooses: 

>e*^{o,i} 

dd  explicitly  sets  (where  attr^  ranges  over  each  leaf  node  attribute  in  the  policy) 
sPdPi  =  t^diszPi) 
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eiPuPaY^^'  ^  Qt 

e{Pi,F2y"^  ^  Gt 

Ci,i  =  5'Ki(attrc)  =  /z;(attrc)Zi 

C\2  =  asF{\{siiirc)  +  jJ-crFi  =  a'/z,(attrc)Zi  +^Fi 

C13  =  -T5‘Ki(attrc)  -  ncrV[  =  -v,/z,(attrc)Zi  -  v'a;/z,(attrc)Zi  -  v'^Fi 

C2,l  =  SP\  =  5zFi 

C2,2  =  asPi  +  ixFi  =  a'(5zFi) 

C2,3  =  -TsPi  -HV[  =  -Vi(szFi)  -  v'.a.(szFi) 


SS  implicitly  sets: 
a\  =  kiU  +  jx' 
fX  =  fx'sz 
^  =  per' 

cr  =  cr'  +  cdhii&iiYc) 

SS  encrypts  under  the  policy  P*^,  using  the  values  above  and  the  algorithm  EncryptQp^^ 

and  returns  the  result  CT cpa- 

A.6.5  Guess. 

sY  returns  its  guess  /?'  to  SS 

If  Zi  is  real  then  CT  cpa  encrypts  a  random  message  under  policy  P*^,  and  simulates 
GameM-random-  If  is  random,  then  CT  cpa  encrypts  a  random  message  under  a  random, 
structurally  equivalent  policy  and  simulates  Game  final-  If  ^  returns  1  if  =  /3'  and  0 
otherwise,  then  it  can  solve  the  A1  problem  with  advantage: 


Adv^^  =  \Pr[J3*  =fi'\Zi  is  real]  -  Pr[fi*  =/3'|Zi  is  random]]  =  \Pr[XM-random]  -  Pr[Xfi„ai]\ 
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Appendix  B:  MA-AHASBE  Implementation  Details 


The  MA-AHASBE  system  is  introduced  in  Chapter  4.  This  chapter  presents  the  details  of 
a  prototype  implementation  of  MA-AHASBE.  The  prototype  implementation  serves  as  a 
proof  of  concept  as  well  as  the  primary  means  of  evaluating  MA-AHASBE  performance. 
The  chapter  first  introduces  the  tools  and  techniques  used  to  build  the  implementation.  The 
next  section  then  describes  issues  that  must  be  addressed  in  an  implementation  that  may 
not  be  obvious  from  the  construction  given  in  Chapter  4.  The  performance  of  the  MA- 
AHASBE  implementation  is  then  presented  and  analyzed.  The  data  is  presented  for  both 
size  and  time.  The  chapter  concludes  with  a  summary  and  some  thoughts  on  future  work. 

B.l  Tools  and  Techniques 

Java  /  C++  /  Qt5  /  MinGW  The  prototype  for  MA-AHASBE  is  primarily  written  in  C++ 
and  uses  the  Qt5  library.  The  code  is  compiled  using  the  MinGW  4.8.1  compiler  for 
Windows.  The  current  codebase  is  designed  to  be  cross-platform  and  could  build  on 
Windows,  Einux  and  MacOS  X.  Java  bindings  to  the  native  C++  have  been  written 
and  the  Java  implementation  of  the  Amazon  Web  Services  Software  Development 
Kit  (AWS  SDK)  is  used  to  interact  with  Amazon’s  cloud  services. 

Sodium  Qt5  provides  SHA  based  hashing  and  message  authentication  code  generation, 
but  does  not  contain  many  other  cryptographic  algorithms.  Sodium  is  used  for 
cryptographic  algorithms  not  provided  by  the  Qt5  library  such  as  AES  and  RSA. 

YAML  YAME  Aint  Markup  Eangauge  (YAME)  is  a  data  serialization  langauge  that  is 
designed  to  be  both  human  readable  and  relatively  efficient  to  process.  It  provides 
similar  functionality  as  other  data  serialization  formats  such  as  JSON  and  XME. 
Eike  JSON  it  provides  methods  for  representing  lists,  associative  arrays  and  scalars. 
It  is  useful  for  representing  tree-based  or  hierarchical  structures,  especially  when  the 
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content  may  need  to  be  read  or  edited  manually.  The  MA-AHASBE  implementation 
uses  the  YAML-CPP  0.5.1  and  Snake YAML  1.14  projects,  which  are  C++  and  Java 
(respectively)  implementations  of  the  YAML  language  for  reading  and  writing  the 
various  data  structures  in  MA-AHASBE. 

RELIC  MA-AHASBE  uses  RELIC  Tookit  0.3.5  [4],  which  is  a  pairing  and  multiple 
precision  arithmetic  tookit.  RELIC  is  used  for  all  finite  field  arithmetic  and  to 
perform  all  pairing  operations.  It  was  chosen  over  another  popular  pairing  library 
PBC  due  to  is  cross  platform  design,  highly  customizable  build  process,  extensive 
unit  testing,  and  support  for  generic  finite  field  arithmetic.  RELIC  has  even  been 
used  for  embedded  wireless  sensor  networks  [84]. 

B.2  Implementation 

This  section  addresses  some  of  issues  that  must  be  addressed  in  an  implementation  of 
MA-AHASBE.  The  mathematical  construction  of  MA-AHASBE  leaves  many  choices  up 
to  the  implementation,  such  as  the  security  parameter  A  or  choice  of  bilinear  group,  and 
the  result  of  these  choices  may  have  a  significant  effect  on  the  performance  of  the  system. 
The  following  list  describes  the  specific  choices  made  for  the  prototype  implementation. 
Elements  listed  in  parenthesis  represent  the  relevant  mathematical  terms  presented  in 
Chapter  4. 

Security  Parameter  (d)  The  security  parameter  is  chosen  to  be  d  =  128.  This  level  of 
security  is  quite  common  for  cryptographic  implementations.  This  means  that  the 
prototype  implementation  can  be  used  to  transport  128-bit  AES  keys  and  provides 
a  reasonable  tradeoff  between  security  and  efficiency.  As  described  in  the  Elliptic 
Curve  entry  below,  there  are  efficiency  advantages  for  pairing  based  cryptography  by 
staying  with  128-bit  security,  particularly  for  Type-3  pairings. 
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Cryptographic  Hash  ('K)  For  this  prototype,  'H  =  S  HA-256.  The  implementation  comes 
from  the  Qt5  library.  It  might  seem  odd  that  SHA-256  was  chosen  rather  than  SHA- 
128  if  T  =  128.  This  is  due  to  the  nature  of  the  underlying  pairing  implementation. 
In  order  to  have  128-bit  security,  points  on  the  elliptic  curve  described  below  are 
elements  of  Zp  where  p  is  a  256-bit  prime  number.  So  a  256-bit  hash  algorithm  is 
a  more  natural  fit  due  to  the  size  of  the  underlying  finite  field  of  the  elliptic  curve, 
rather  the  security  parameter.  In  addition  to  its  uses  as  described  in  Chapter  4,  this 
hash  has  two  other  important  functions.  First,  it  creates  a  unique  name  for  each  global 
or  public  parameter  that  is  created  through  the  GlobalSetup  and  AuthoritySetup 
algorithms  respectively  by  hashing  the  contents  of  the  parameters  to  be  used  as  a 
reference  throughout  the  system.  Secondly,  the  construction  in  Chapter  4  describes 
the  entries  in  identity  tuples  as  being  elements  of  Zp.  In  a  real  world  implementation, 
however,  these  elements  tend  to  be  strings.  The  hash  algorithm  'H  is  used  to  map  text 
strings  to  elements  of  Zp  by  the  calculation:  id  =  'H{\D string)  mod p  where  id  6  Zp 
and  \D string  represents  a  string  value  such  as  “Student”  or  “University”.  Since  'H  is 
a  cryptographic  hash  algorithm  and  therefore  collision  resistant,  in  practical  terms 
(and  with  high  probability)  this  mapping  will  be  bijective  over  the  strings  used  for 
identities. 

Pairwise  Hash  (h)  In  order  to  perform  the  CCA  transformation  described  in  [19],  a  hash 
function  from  a  family  of  pairwise  independent  hash  functions  must  be  selected. 
For  MA-AHASBE,  the  relatively  straightforward  approach  described  in  [26]  is  used. 
This  is  done  with  the  following  formula:  h(x)  =  ((ax  ■+■  b)  mod  q)  mod  m  where  x  is 
an  value  to  be  hashed,  ^  is  a  448  bit  prime  number,  a,  b  6[/  Z*  and  m  is  2^^^.  Note 
that  this  hash  function  is  only  used  to  generate  a  key  to  the  MAC  algorithm  which 
only  requires  a  128-bit  key,  and  is  not  used  to  map  to  finite  field  elements  or  points 
on  the  elliptic  curve.  Therefore,  unlike  HI,  its  values  can  remain  128-bits  in  size. 
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Elliptic  Curve  {p,  e,  Gi,  G2,  Gt)  The  choice  of  elliptic  curve  is  narrowed  down  by  the 
pairing  library  RELIC  and  the  fact  that  MA-AHASBE  is  based  on  Type-3  pairings. 
At  the  128-bit  security  level,  Baretto-Naehrig  (BN)  curves  [10,  35,  88]  are  the  most 
efficient  curves.  The  choice  of  generators  for  each  group,  the  prime  p,  and  the 
implementation  of  the  pairing  e  is  based  on  the  BN  family  of  curves.  This  is  also 
the  default  choice  for  asymmetric  pairings  in  RELIC. 

Random  Number  Generation  In  cryptographic  implementations,  the  source  of  entropy 
can  become  very  important  in  terms  of  both  performance  and  security.  Sources 
with  higher  entropy  (good  for  cryptographic  purposes)  such  as  an  operating  system’s 
secure  random  generator  can  often  incur  a  latency  cost  in  order  for  the  operating 
system  to  ensure  enough  entropy  is  available  in  the  result.  Other  sources  can  offer 
quicker  results  (good  for  performance),  but  may  have  lower  amounts  of  overall 
entropy  (bad  for  cryptographic  purposes).  The  random  number  generator  in  the 
MA-AHASBE  implementation  is  set  to  draw  from  the  operating  system’s  secure 
random  number  generator.  Specifically,  the  results  in  this  chapter  are  using  the 
CryptGenRandom  function  which  is  part  of  the  Windows  cryptographic  application 
programming  interface. 

Data  Structure  Representation  In  an  actual  implementation,  the  data  structures  presented 
in  Chapter  4  must  have  some  type  of  in-memory  and  on-disk  representation.  This  in¬ 
cludes  global  parameters,  authority  parameters,  policies,  ciphertexts,  keys,  and  key 
rings.  While  the  parameters  and  keys  are  relatively  flat,  the  policies  and  ciphertexts 
have  a  hierarchical  aspect  to  them.  YAML  was  chosen  as  a  data  serialization  format 
because  it  is  easy  to  manipulate  the  variety  of  data  structures  found  in  MA-AHASBE. 
Also  as  a  prototype  implementation,  it  is  important  that  the  data  serialization  format 
is  easily  readable  and  writable  by  a  human  to  facilitate  development.  YAML  uses 
significant  whitespace,  which  means  that  whitespace  has  syntactical  meaning.  While 
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this  helps  boost  readability,  it  also  has  a  some  cost  in  terms  of  the  size  of  the  data 
structures. 

Finally,  it  is  worth  noting  items  mentioned  in  Chapter  4  that  are  not  a  part  of  the  current 
implementation.  The  following  items  are  currently  not  implemented: 

•  Cross  domain  attributes 

•  Updating  single  attributes  of  key  structures 

•  Decentralized  global  parameter  generation  through  SMPC 
B.2.1  Side  Effects  and  Optimization. 

Before  discussing  the  performance  metrics,  it  is  worth  noting  that  the  implementation  of 
MA-AHASBE  is  not  optimized  nor  rigorously  scrubbed  for  potential  side  effects.  In  the 
case  of  optimization,  the  design  of  the  implementation  has  been  focused  on  the  practicality, 
reliability  and  clarity  of  the  code  rather  than  on  its  performance.  As  such  it  could  be 
expected  that  another  design  with  a  heavier  emphasis  on  performance  would  perform  faster. 
On  the  other  hand,  the  code  has  not  been  thoroughly  analyzed  for  potential  side  effects. 
As  is  often  the  case  with  implementations  of  cryptographic  algorithms,  the  most  serious 
vulnerabilities  are  discovered  through  so  called  side-channel  analysis.  Side  effects  are 
introduced  in  cryptographic  implementations  when  there  exists  some  detectable  difference 
in  performance  when  executing  operations  with  sensitive  key  data.  The  performance 
difference  could  be  in  terms  of  power  usage,  sound  emissions,  heat,  time,  or  a  variety  of 
other  factors.  RELIC  offers  a  variety  of  options  to  select  algorithms  that  are  less  susceptible 
to  this  type  of  analysis.  Eor  example,  RELIC  can  use  the  Montgomery’s  ladder  technique 
to  perform  elliptic  curve  point  addition.  This  technique  is  not  as  efficient  as  other  more 
direct  techniques,  but  involves  a  deterministic  set  of  operations  that  is  independent  of  the 
operands.  So  while  further  optimization  could  improve  the  implementation  performance, 
a  more  robust  check  of  potential  side  effects  could  result  in  potentially  slower  algorithms. 
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In  the  end,  the  prototype  implementation  is  not  designed  to  be  produetion  quality,  but  to 
serve  more  as  an  indieator  to  what  MA-AHASBE  performanee  might  be  in  a  real-world 
implementation. 

B.3  Performance 

The  performanee  of  MA-AHASBE  is  primarily  dependent  on  policy  size,  but  if  certain 
attribute  protection  mechanisms  are  used  the  performance  can  also  depend  on  the  number 
of  decryption  keys  possessed  by  the  decrypting  party.  In  order  to  present  the  performance 
characteristics,  two  examples  have  been  chosen  to  demonstrate  to  points  of  complexity. 
The  first  scenario  has  a  relatively  simple  policy,  while  the  second  scenario  contains  a  more 
complex  policy  with  the  attribute  protection  mechanism  turned  on.  The  first  policy  is  shown 
in  Eigure  B.l  and  the  second  policy  is  shown  in  Eigure  B.2. 
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Eigure  B.l:  Scenario  1 


Information  regarding  the  policy  sizes  are  shown  in  Table  B.l.  The  size  of  the  key  rings 
necessary  for  decryption  are  shown  in  Table  B.2.  Einally,  the  time  required  for  performing 
encryption  and  decryption  is  shown  in  Table  B.3.  Each  result  shows  the  average  of  five 
samples,  with  the  standard  deviation  shown  in  parenthesis. 
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Figure  B.2:  Scenario  2 


Scenario  1 

Scenario  2 

Domains 

1 

4 

Total  Nodes 

7 

17 

Leaf  Nodes 

3 

7 

Hidden  Nodes 

0 

1 

Policy  Size 

0.295  kb  (0.001) 

1.552  kb  (0.002) 

Ciphertext  Size 

1.505  kb  (0.004) 

3.289  kb  (0.003) 

Table  B.l:  Policy  Sizes 


B.4  Sign/Verify  Constructions 

Constructions  for  creating  and  verifying  signatures  with  MA-AHASBE  are  presented 
without  proof  here  (the  proof  should  be  a  straightfoward  application  of  the  argument 
presented  in  [47]  regarding  hierarchical  IBE): 
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Scenario  1 

Scenario  2 

Domains 

1 

4 

Attribute  Sets 

1 

8 

Attributes 

4 

13 

Key  Ring  Size 

5.412  kb  (0.005) 

16.251  kb  (0.015) 

Table  B.2:  Key  Sizes 


Scenario  1 

Scenario  2 

Hidden  Node  Recovery 

N/A 

0.562  s  (0.194) 

Key  Ring  Generation 

1.680  s  (0.038) 

5.329  s  (0.027) 

Encryption 

0.091  s  (0.002) 

0.221  s  (0.002) 

Decryption 

1.007  (0.008) 

2.613  s  (0.207) 

Table  B.3:  Timing 


Sign(GP,  PPa,  M,  US K, IT) attribute)  Let  H{M)  mod  p  =  m  where  H{M)  is  the  crypto¬ 
graphic  hash  of  the  input  message.  Run  Delegate(17SK,  PPa,  IDattribute  =  (idi, id^,  m  = 
id^+i,  ^  -I-  1).  Return  cr  =  (m, IDattribute,  J)  where  J  is  the  set  of  J  components  in  the  key 
returned  by  the  Delegate  algorithm. 

Yerity(GP,  M,  PPa,  IDattribute,  O')  Let  H{M)  mod  p  =  m  where  H{M)  is  the  crypto¬ 
graphic  hash  of  the  input  message.  If  m  or  IDattribute  do  not  match  their  corresponding 
values  in  the  signature,  return /a/^e.  Let  attr^  =  {ID attribute,  m).  Create  a  set  of  cipher- 
texts  similar  to  those  created  for  a  local  leaf  node  in  the  Encrypt  algorithm,  but  without 
multiplying  by  the  value  qt{0)-  Then  run  the  DecryptNode  algorithm  on  the  ciphertext  as 
if  it  was  a  local  leaf  node,  replacing  the  K  components  with  the  J  components  from  the 
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signature.  If  the  result  is  equal  to  one,  then  the  signature  verifies  and  return  true.  Return 
false  otherwise.  The  decryption  equation  is  given  below: 

,  ]_  -^1,3)  ]_  e(-Ki(attr„),W2P2+'-3V2MQ'Hi(attr„),r3Vpe(-T^i(attr„),r3F2) 

“  e(C2,i ,  J2,l)e(C2,2,  J2,2)e(C2,3,  72,3)  ~  4Pi,W2W2(attr„)+r4V2).(«P,,r4Vp.(-rP,,r4f2) 

]_  e{^i  (attreom),P2)"'2  e{^i  (attr„), V2)''3  eCHi  (attr™)^^”^  e{^i  (attr„),f2)^"''3 

e(P,  ,'W2(attr„))“’2  e(Pi  .ViY*  e{Pi  ,yp“''4  e(P,  ,r’2)^"4 
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Appendix  C:  Notes  on  Encrypted  Search  and  Real-Time  Collaboration 


The  attribute-based  encryption  system  presented  in  Chapters  4  and  5  addresses  the  problem 
of  encrypting  documents  in  preparation  for  storing  them  in  the  cloud.  However,  once 
encrypted  documents  are  placed  in  the  cloud,  the  CSP  is  now  limited  in  the  amount  of 
processing  and  services  it  can  provide.  Therefore,  performing  text  based  search  over 
encrypted  documents  is  a  critical  task  in  order  to  consider  placing  a  large  volume  of 
potentially  sensitive  documents  on  untrusted  cloud  resources.  This  appendix  examines 
how  MA-AHASBE  can  be  combined  with  existing  encrypted  search  techniques  to  provide 
an  end-to-end  solution. 

C.l  Related  Work  on  Enrypted  Search 

Storing  encrypted  documents  in  the  cloud  reduces  amount  of  trust  a  user  needs  to  place 
in  the  CSP,  but  at  the  same  time  it  also  restricts  the  useful  things  that  the  CSP  can  do 
with  the  data.  Perhaps  the  most  straightforward  consequence  is  that  it  is  no  longer  a 
straightforward  task  to  index  and  search  over  the  store  of  documents.  Text  search  and 
information  retrieval  have  become  cornerstones  of  a  digital  age.  Due  to  the  popularity  of 
Internet  search  engines,  keyword  based  search  with  ranked  results  has  become  a  natural 
way  to  perform  information  retrieval  over  a  large  collection  of  documents.  Search  engines 
are  able  to  build  their  search  indices  quickly  and  efficiently  because  the  engines  have  direct, 
plaintext  access  to  the  documents. 

One  approach  is  to  encrypt  all  data  client-side  before  sending  it  to  the  CSP.  While  this 
does  prevent  the  CSP  from  accessing  potentially  sensitive  data,  it  could  also  prevent  the 
CSP  from  doing  any  meaningful  work  on  the  data.  A  motivating  example  is  the  service 
of  providing  keyword  search.  Traditional  search  engine  indexing  schemes  rely  on  having 
access  to  the  plaintext  data  in  order  to  create  efficient  search  indices  in  order  to  quickly 
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return  the  most  relevant  results  to  a  user  query.  A  plaintext  search  engine  can  perform 
sophisticated  lexical  analysis  of  both  the  search  query  terms  as  well  as  the  underlying 
dataset  independent  of  any  client  processing  of  the  data.  However,  when  the  dataset  is 
encrypted  on  the  client  side,  the  client  must  assume  responsibility  for  processing  the  data. 
Therefore,  minimizing  this  processing  burden  on  the  client  while  maintaining  the  security 
and  privacy  benefits  of  client-side  encryption  are  desirable  properties  of  an  encrypted 
search  algorithm. 

It  is  worthwhile  to  note  that  the  concept  of  remote  encrypted  storage  retrieval  is  distinct 
from  another  related  concept  of  private  information  retrieval  (PIR).  With  PIR,  the  goal  is  to 
allow  users  to  make  queries  on  a  shared  database  without  other  parties  or  the  database  server 
knowing  the  contents  of  the  query.  Often  PIR  systems  utilize  databases  that  are  stored  in 
plaintext,  since  the  goal  is  not  to  protect  the  stored  information,  but  rather  the  query.  This 
is  not  the  same  as  protecting  the  content  of  the  data  stored  on  a  remote,  untrusted  server. 
One  of  the  earliest  papers  to  discuss  the  topic  of  remote  encrypted  storage  retrieval  by 
keyword  was  by  Song  et.  al  [96].  Building  on  this  work,  a  number  of  additional  papers  have 
since  been  published  proposing  various  enhancements.  A  method  for  efficient  conjunctive 
keyword  search  is  described  by  Golle  et  al  in  [50].  Proposed  improvements  to  this  method 
are  in  [22]  and  [7].  However,  analysis  of  [22],  [7]  show  they  may  not  be  semantically 
secure  as  described  in  [61].  Another  set  of  attacks  on  conjunctive  keyword  search  schemes 
is  described  in  [92].  This  illustrates  that  it  is  not  trivial  to  extend  these  cryptographic 
systems  in  ways  that  provide  efficient  indexed  search  as  well  as  preserving  privacy.  In 
addition  to  conjunctive  search,  techniques  for  fuzzy  keyword  searches  are  found  in  [8], 
[9]  and  [10].  Finally,  techniques  for  performing  ranked  keyword  search  can  be  found  in 
[24,  25,  106,  107].  The  system  presented  in  [25]  called  MSRE  represents  the  state  of  the 
art  in  multi-keyword  ranked  search. 
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C.1.1  Homomorphic  Encryption. 

Homomorphic  encryption  is  often  cited  as  the  gateway  to  remote  encrypted  storage  and 
private  cloud  computing.  Homomorphic  encryption  allows  a  third  party  to  perform  a 
arithmetic  operation  (such  as  add,  subtract,  multiply  and  divide)  on  the  encrypted  form  of 
data  without  having  the  decryption  key,  and  the  effect  will  carry  over  to  the  corresponding 
plaintext.  Many  encryption  schemes  used  in  public  key  cryptography  have  natural 
homomorphic  properties.  These  schemes  are  usually  only  homomorphic  for  some  subset  of 
operations,  such  as  just  addition/subtraction  with  Paillier  [85],  or  multiplication  with  RSA 
[93].  These  schemes  are  referred  to  as  partially  homomorphic  encryption  systems. 

The  first  fully  homomorphic  scheme  was  discovered  by  Gentry  [45].  It  uses  a  worst 
case  generation  of  an  ideal  lattice  structure  and  the  difficulty  of  searching  through  such  a 
structure  to  bootstrap  a  partially  homomorphic  system  into  a  fully  homomorphic  encryption 
system.  Since  Gentry’s  discovery,  improvements  on  the  efficiency  of  this  system  have 
been  made.  Research  has  also  been  done  on  the  practical  applications  of  homomorphic 
encryption  [16]. 

A  major  challenge  for  fully  homomorphic  encryption  algorithms  to  be  used  in  search  over 
encrypted  data  is  the  large  cost  of  encryption  and  decryption,  as  well  as  key  generation  and 
storage.  For  example,  the  implementation  of  Gentry’s  algorithm  in  [46]  describes  “small” 
key  sizes  of  70  Megabytes  and  “large”  key  sizes  of  2.3  Gigabytes.  Also  the  time  to  generate 
these  keys  range  from  30  seconds  for  the  small  case  and  30  minutes  for  the  large  case.  Some 
more  recent  work  at  optimizing  fully  homomorphic  encryption  schemes  has  been  done 
using  ring  learning  with  error  (RWLE)  problems  [20,  98].  Even  as  the  efficiency  of  fully 
homomorphic  encryption  algorithms  increases,  the  applications  so  far  require  encrypting 
each  bit  or  token  of  plaintext  using  the  fully  homomorphic  encryption.  In  practical  systems, 
this  operation  is  too  expensive  even  for  partially  homomorphic  encryption  such  as  RSA. 
Typically,  a  fast  symmetric  key  is  used  for  bulk  encryption  of  data.  The  symmetric  key. 


155 


which  is  very  small  compared  to  the  size  of  the  data  that  needs  to  be  protected,  can  then 
itself  be  protected  through  a  more  expensive  operation  such  as  Paillier  or  RSA.  It  seems 
that  if  homomorphic  encryption  will  be  used  in  securing  cloud  computing,  that  it  will  be  in 
conjunction,  rather  than  in  place  of,  traditional  cryptographic  concepts  such  symmetric  key 
encryption,  public  key  encryption  and  secure  hash  techniques.  The  difficulty  of  mapping 
a  fully  homomorphic  encryption  primitive  to  the  general  class  of  private,  multi-client 
computing  problems  as  described  in  [103]  is  still  an  open  research  problem. 

C.2  Multi-Keyword  Ranked  Search  Over  Encrypted  Data 

The  multi-keyword  ranked  search  over  encrypted  data  algorithm  MSRE  [25]  is  a  recent 
advancement  in  the  area  of  encrypted  search.  It  uses  a  variation  of  a  secure  k-nearest 
neighbor  search  using  a  document  vector  model.  In  this  approach,  documents  are 
represented  as  vectors  in  a  vector  space.  A  query  consists  of  various  keywords  that 
represent  content  the  user  is  interested  in.  When  a  query  is  made,  it  is  first  converted 
to  a  vector  in  the  same  manner  as  documents.  This  query  vector  is  then  compared  against 
every  document  in  the  collection,  using  the  cosine  of  the  angles  of  the  vectors  as  a  similarity 
measure.  Query  and  document  vectors  that  are  oriented  in  the  same  way  in  vector  space 
are  assumed  to  be  closely  related.  Since  the  similarity  measure  comes  out  as  a  numerical 
quantity,  it  also  provides  for  a  ranking  of  the  similarity.  MSRE  uses  a  symmetric  key 
to  protect  both  the  contents  of  the  query  and  the  indices  built  from  the  documents.  The 
primary  limitation  is  that  the  dictionary  size  used  to  build  the  indices  must  be  a  fixed  size. 
Also,  MSRE  requires  a  security  parameter  that  trades  security  for  search  accuracy.  MSRE 
appears  to  be  a  promising  approach  for  doing  keyword  searches  over  encrypted  data. 

C.3  Related  Work  on  Group  Collaboration 

Work  on  real-time,  group  collaboration  algorithms  date  back  to  1989  to  the  work  of  Gibbs 
and  Ellis  [36].  This  introduced  the  idea  of  the  operational  transformation  (OT)  which  is 
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an  algorithmic  strategy  that  addresses  the  issues  that  arise  in  high  latency,  concurrent,  real¬ 
time  systems  that  require  a  shared  working  state.  The  advantages  of  the  OT  algorithm 
is  that  it  does  not  require  locks  and  edits  to  the  shared  state  can  be  applied  to  the  local 
copy  immediately.  In  order  for  the  OT  algorithm  to  work,  there  must  be  a  transformation 
algorithm  that  can  work  pairwise  over  every  type  of  operation  (e.g.,  add  a  character,  remove 
a  character,  move  cursor).  The  transformation  algorithm  is  used  to  effectively  reorder 
operations  that  arrive  from  remote  clients.  This  process  allows  local  edits  to  be  applied 
immediately,  which  reduces  the  perception  of  latency  to  the  local  user.  The  OT  algorithm 
can  then  process  any  remote  edits  that  were,  with  respect  to  global  time,  performed  before 
the  local  edits.  This  reduces  the  impact  of  a  high  latency  communication  channel  and  is 
perfectly  suited  for  applications  such  as  real-time  document  editing. 

C3.1  SPORC. 

SPORC  [37]  is  a  group  collaboration  protocol  that  operates  on  a  security  model  of  untrusted 
servers.  It  combines  the  previous  techniques  of  OT  and  fork*  consistency.  In  order  to 
detect  malicious  servers,  the  protocol  relies  on  the  clients  in  the  system  having  access  to  an 
out-band  communication  channel  in  order  to  detect  if  the  server  is  malicious;  though  this 
channel  may  be  very  low  bandwidth.  The  role  the  server  is  reduced  to  providing  availability 
of  the  data,  which  works  well  under  the  A-Trusted  security  paradigm  discussed  in  Chapter 
5. 
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